03 — Case Studies
Selected work
Three projects from my Veradigm internship, one cross-industry analysis set, and one independent SQL project with the code published. The internship work is written to respect confidentiality: aggregate figures only, no client or vendor names, no internal system detail. Each one notes where the same approach transfers.
01
Three workbooks, one dashboard, zero untraceable numbers
DATA CONSOLIDATIONRECONCILIATIONSTAKEHOLDER REPORTING
The problem
A partner program's reporting lived in separate workbooks — one for certifications, one for client activation requests, one for subscription accounts. Answering a basic program question meant opening all three, and no two answers were guaranteed to agree.
What I did
Consolidated 3,000+ records into a four-tab analytics dashboard with a shared structure across views. Every metric drills down to the underlying records and exports to CSV, so any number on screen can be traced and taken away by whoever's asking.
The judgment call
Before shipping I reconciled the dashboard field by field against the source workbooks and dropped every figure the sources couldn't support. Trust was the actual feature: a metric nobody can trace gets ignored, and a wrong one gets remembered.
Outcome
Questions that used to require three files now have one answer in one place. It took 17 versions of stakeholder feedback and reconciliation passes before I called it done.
3,000+records consolidated
4integrated views
100%metrics traceable to source
Transfers toSales and revenue ops reporting, vendor and supplier programs, finance reconciliation, membership or subscription reporting — anywhere the same entity is tracked in more than one system.
02
Finding where support burden actually comes from
TAXONOMY DESIGNOPERATIONS ANALYSISPERFORMANCE ENGINEERING
The problem
A support-reduction initiative had a goal but no starting line. Roughly 11,000 support tickets across 700+ vendor accounts existed only as unstructured titles in a queue. Nobody could say where the burden came from, so nobody could prove it was shrinking.
What I did
Derived a two-level classification taxonomy (12 categories, ~35 topics) from the free-text titles and applied it across the full dataset with zero records left uncategorized. That exposed the distribution for the first time: a small group of accounts drove nearly half of all volume, and self-service opportunities clustered in a handful of predictable categories.
The judgment call
The analysis shipped as a self-contained browser dashboard that started at 2.3 MB — too heavy to share. I rebuilt the data layer with dictionary encoding, column-oriented storage, and compression, cutting it to 466 KB, then verified full data parity myself across every record and field before anyone saw it.
Outcome
The initiative got measurable baselines for its key results, and leadership got a shareable view of where support effort actually goes instead of anecdotes about it.
~11Ktickets analyzed
0uncategorized records
4.9×smaller payload, full parity
Transfers toCustomer support and success analytics in any industry, SaaS onboarding, call-center and service-desk operations, ecommerce returns analysis, IT service management — every queue-based system has this same hidden concentration.
03
An internal tool for people who can't see their own data
UX & VISUALIZATIONALERT DESIGNTEAM OF 4 · 5 WEEKS
The problem
Analysts working inside a client's data had no easy way to see when data quality slipped, or where. Our four-person team entered the company's internal innovation challenge with a data-quality monitoring dashboard, and five weeks to make it real.
What I owned
Two of six workstreams: the interface and the alerting. The design rule for the interface was the first thirty seconds — opening it should tell you what's wrong, where, and how serious, before you click anything. The alerting side was about who gets told when a metric slips, and how to route that without drowning people in noise.
The judgment call
Access control shaped the design as much as usability: views masked by default, small groups suppressed to protect individuals, every data reveal written to a log. And a week before presenting, we cut every claim the shipped code didn't actually back — our refresh ran on a daily cycle, not in real time, and saying so plainly beat getting caught on it in Q&A.
Outcome
We presented to a senior leadership panel and took five minutes of questions harder than any of our dry runs, which is what we'd practiced for. Precise beat polished.
15:00on the leadership clock
2 of 6workstreams owned
30stime-to-understanding target
Transfers toInternal tooling and admin interfaces, data governance and observability programs, alerting and on-call design, any product where role-based permissions and audit trails matter — finance, HR systems, education, government.
04
A dozen public datasets, four unrelated industries
TABLEAUEXCEL MODELINGEXPLORATORY ANALYSIS
The problem
Through USF's Global Career Accelerator, I worked through roughly a dozen public datasets from domains with nothing in common: transportation, streaming media, municipal transit, and advertising.
What I did
Built Tableau dashboards and Excel models across NYC taxi fare data, YouTube trending-video performance, BART ridership, and Super Bowl advertising — using calculated fields, PivotTables, and XLOOKUP to surface behavioral and distribution patterns in each.
Why it's here
It's the clearest evidence that my method isn't domain-bound. Different subject matter, same discipline: understand how the data was collected, find what's missing or miscoded, then look for the pattern that answers an actual question rather than the one that looks good on a chart.
~12public datasets
4unrelated domains
Transfers toAny analyst role where you'll be handed unfamiliar data and expected to get oriented fast — which is most of them.
05
Where a city’s work concentrates, answered in SQL
SQLWINDOW FUNCTIONSDATA QUALITYPUBLIC DATA
The problem
Every city runs a queue. Someone reports a pothole, a broken heater, a rat, and that report joins millions of others. New York publishes all of it, so I took the same question I’d asked of a support-ticket backlog and asked it of a city: where does the volume actually concentrate, how long do people wait, and which addresses report the same problem over and over?
What I did
Wrote seven query modules against millions of 311 service requests, with SQL doing the analytical work rather than pulling rows out for pandas to handle: running totals for Pareto concentration, LAG partitioned by address and complaint type to find repeat events, LAG(n, 12) for year-over-year change, RANK within complaint type so agencies handling different work aren’t compared unfairly, percentile aggregation for median and p90 wait times, and conditional aggregation for the data-quality audit.
The judgment call
A meaningful share of records close before they open. That’s impossible. Deleting them understates how much work came in; keeping them produces negative durations that drag every median down. I kept them in volume counts, excluded them from duration math only, and flagged them — with the reasoning written into the SQL beside the code that implements it, not buried in a script. The audit query reports the exact share so a reader can judge whether it’s small enough to live with.
What I’d point to
A 28-assertion test suite that checks whether queries are correct, not merely whether they execute. It caught two bugs that would have shipped plausible wrong answers: a GROUP BY that silently split a window partition and undercounted repeat complaints, and a query returning zero rows because the test fixture gave every complaint type exactly one agency. The second one is the failure mode I think about most — a query that errors gets fixed, a query that runs and returns nothing gets shipped.
7query modules
28correctness assertions
2logic bugs caught
0hand-typed findings
Code, SQL, and full findings on GitHub →
Transfers toAny operational queue — service desks, claims backlogs, work orders, permit pipelines, case management. The concentration and repeat-event patterns behave the same way whatever the records are called, and the data-quality questions are always the ones that decide whether the answer holds.