Recording Baseline Dashboard Suite

The Problem

The company processes hundreds of thousands of eRecording packages per year across four separate legacy recording systems. Despite that volume, there was no centralized place for the team to see operational health — volume trends, rejection rates, match rates, turnaround times, or cost signals. Each system lived in its own silo; operations leads relied on tribal knowledge and ad-hoc queries. Meanwhile, a new recording platform was under active development with program goals targeting cost avoidance, time reduction, and system consolidation. Without baselines, the program would have no way to prove the new platform was working. You can’t measure improvement without a “before.”

The Solution

I delivered a production-deployed suite of five dashboards covering executive visibility, legacy system operations, match health for one pipeline, source-system segmentation for the other two systems being consolidated, and a pilot tracking view for a new matching strategy. For the first time, the recording team can open a link and see the health of the entire legacy recording operation in one place — and when the new platform’s metrics come online, they have a documented “before” to measure against.

Outcome & Impact

Nine hours of focused work produced a five-dashboard suite with more than 40 production queries covering volume, quality, cost, and pilot tracking across all four legacy systems — work that would typically take two to three weeks of analyst or engineer time without AI assistance.

The dashboards deliver the first centralized view of recording operational health in the organization’s history. The account filter alone prevents the six-times volume inflation that would have undermined stakeholder trust in every metric. The pilot dashboard gives leadership a data-driven substrate for deciding whether to expand the new matching strategy beyond the initial test offices. And the explicit “Future Overlay” documentation creates a measurement contract for the program: these are the numbers the new platform will be compared against.

My Role & Contributions

Aspect	Detail
Role	Product manager acting as analyst-builder
Team size	1
Timeline	~9 hours of focused work
Scope	Metric definition, dashboard architecture, SQL across four legacy systems, deployment
Key decisions	Which metrics matter per audience; dashboard consolidation strategy; data quality filter that excluded irrelevant data; pilot success metric definition; framing as baselines rather than progress metrics

Technical Overview

Legacy System A (SQL Server → data lakehouse)
├── Orders, fees, statuses, county data
└── → Operational dashboard (daily refresh)

Legacy System B (DynamoDB export → data lakehouse)
├── Packages, match logs, delivery, vendor accounts
└── → Match health dashboard

Legacy Systems C & D
└── → Segmentation dashboard

                    ↓
         Databricks Lakeview Dashboards
         (2 deployments, 5 total views)

Two of the four legacy systems are entirely independent pipelines with no data overlap — their volumes are additive with no deduplication needed. This architectural reality drove the consolidation decision: four dashboard tabs for the weekly operational view and one standalone dashboard for the system requiring daily operational triage.

Critical data quality decision: the account filter

The most consequential implementation decision was a data quality filter applying domain knowledge about how one pipeline’s vendor accounts work. Without this filter, dashboards would have shown roughly six times the volume that system is actually responsible for, inflating every metric. Applying it as a strict join (rather than a conditional filter) ensured the exclusion held in all aggregations, not just top-level counts. This was tribal knowledge with no documentation — the kind of thing that separates a useful dashboard from a misleading one.

Pilot measurement design

One dashboard tracks a pilot program testing a new matching strategy across a subset of offices. The resolution indicator for the pilot is a non-obvious field: using the most intuitive status field would have measured the wrong matching path entirely. I identified the correct success signal and added a control group of comparable non-pilot offices in the same region, so leadership has a valid comparison for the go/no-go decision.

Challenges & Key Decisions

Data quality as the hidden problem

The biggest risk wasn’t building charts — it was building charts that show the wrong thing. The account filter that excludes irrelevant pipeline data is tribal knowledge with no documentation. Without it, executive dashboards would have shown misleadingly large volume numbers and artificially suppressed match rates. AI assistance compressed the SQL coding time dramatically, but identifying which data to include required understanding how the underlying systems actually work.

Baselines, not progress metrics

I explicitly scoped the dashboards to measure the current state of legacy systems, not the new platform’s performance. The new platform wasn’t emitting data yet, so trying to build progress metrics would have produced empty charts. Framing the deliverable as “baselines” also set stakeholder expectations correctly: these measure today, and the new platform’s metrics will overlay on top of them.

Dashboard consolidation for adoption

Originally planned as five separate dashboards. Consolidated into two deployments — one multi-tab suite for weekly operational review and one standalone for daily triage — based on different refresh cadences and audiences. Five separate links would get lost; two links with clear purposes reduces cognitive overhead for the team.

Lessons Learned

• Domain knowledge is the real moat. The SQL is straightforward. Knowing which accounts to include — and that this filter changes every metric by six times — is the tribal knowledge that separates useful dashboards from misleading ones. AI assistance compresses the coding time; it doesn’t replace knowing the data.
• “Baselines, not progress metrics” is a useful scope boundary. It prevents building what doesn’t exist yet and sets stakeholder expectations correctly from the start.
• AI acceleration changes the economics of PM-built tooling. Nine hours for a five-dashboard suite means a product manager can build operational visibility that would otherwise wait weeks in an analyst’s backlog. The bottleneck shifts from “how long to build” to “do you know what to measure.”