The Problem That Made Everyone's Life Hell

Quarterly business reviews had turned into disasters. Our sales reps would walk into meetings with enterprise customers managing thousands of rides per month, and nobody—not the customer, not our team—could make sense of what was actually happening. Customers were stagnant, signed up but not growing, because they had zero visibility into how their people were using Lyft.

What I Built

I created a standardized customer reporting system using SQL queries and Google Data Studio that gave our 20 biggest customers real-time visibility into their ride patterns, complete with dashboards that explained billing discrepancies and provided actionable insights.

The System Was Completely Broken

Here's what was happening: Sales reps would scramble before every QBR, hunting down anyone with database access—engineering, customer success, whoever—begging for reports. They'd get raw data dumps with no analysis, hand them to customers, and then watch everything fall apart.

The customers would compare these reports to their invoices, nothing would match, and trust would evaporate. Why? Because our business reporting used ride dates (when the trip happened) but billing used transaction dates (when the credit card was charged). A ride on the 31st might not get billed until the next month. Across thousands of rides, nothing tied out.

Meanwhile, our engineering and customer success teams were drowning in random data requests from sales reps who couldn't even explain what they needed the reports for.

How I Thought About the System

I mapped the entire quote-to-cash flow and realized the core issue wasn't data accuracy—it was data alignment and explanation. We had incredibly rich data (ride types, geofencing, coupons, timestamps, locations) but zero standardization in how we packaged it for customers.

The constraint was clear: we needed something scalable that didn't require engineering resources for every customer request, but that could still provide the depth our enterprise customers needed to understand their programs.

What I Actually Built

I created two standardized SQL queries against our business system that sales reps could run themselves—just input customer name and date range, nothing else. The queries pulled structured data on ride patterns, locations, times, and usage types.

Then I built customer-facing dashboards in Google Data Studio (free tool) for each of our top 20 customers. Sales reps would run the query, copy the data into the dashboard as the source, and it would automatically refresh with charts, tables, and insights.

The key was the watermarking: every dashboard clearly explained why billing discrepancies existed, making it educational rather than confusing. "This is business reporting based on ride dates. Your invoices use transaction dates. Here's why they don't match—and why that's actually normal."

The Impact Was Immediate

Quarterly business reviews transformed from damage control sessions into strategic conversations. Customers could finally see where rides were going, what times of day people traveled, which facilities were most popular, whether people were using Lyft for commutes or meetings.

Engineering went from getting hundreds of custom reporting requests to essentially zero. Customer success stopped being data extractors and became actual success partners. Sales reps stepped into trusted advisor roles because they could walk into meetings with real insights, not just raw numbers.

Most importantly: customers started growing again. When you can see that 40% of your rides are between offices during lunch, you can design programs around that. When you understand usage patterns, you can optimize.

The Real Win

This was the moment I realized that most "data problems" are actually trust and communication problems. The data was always good—we just weren't packaging it in a way that built confidence and enabled action.