A waste hauler's ops and marketing finally read from one dashboard

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

The hauler runs residential and commercial collection across a metro area, plus a composting service it is actively growing. Route operations live in a dispatch system, new customer sign-ups arrive through the website, and service-request volume accumulates in a shared inbox. The general manager reviews the business weekly and has historically assembled that review from three people's screens the morning of the meeting. Growth decisions — where to add capacity, which neighborhoods justify another route — are made from experience and instinct, because the numbers live in systems that do not talk to each other.

What it was costing

Route operations lived in a dispatch system, customer sign-ups on the website, and service-request volume in email; the GM asked weekly which neighborhoods were growing and which routes were stressed, and got a shrug assembled from three people's screens.

What they could see

• The weekly GM question — which neighborhoods are growing and which routes are stressed — got a different answer depending on who was asked.
• Sign-up volume by neighborhood existed in the website's world and route loads in dispatch's world, never in the same place.
• Service requests sat in email, so the busiest pockets of demand were invisible until they became complaints.
• The Monday review was rebuilt by hand every week, and its numbers could not be reproduced a week later.

The constraints we worked inside

• The dispatch system exports weekly; the dashboard must be honest about data age rather than pretending freshness.
• Marketing and ops measure different success — sign-ups vs route density — but share geography; the dashboard must join them without flattening either.
• Drivers and dispatchers won't use a dashboard; this is for the GM's decisions, not the cab.

What had been tried before

Dispatch ran a weekly operations summary from its own system, circulated as a PDF to the leadership group.

It covered routes only and knew nothing about sign-ups or web demand, so it answered operational questions while the growth questions stayed unanswered.

The office manager kept a spreadsheet joining sign-up counts to neighborhoods from memory and monthly exports.

Neighborhood names were typed freehand against no reference list, so the same area appeared under three spellings and the totals never survived scrutiny.

What we proposed

We proposed one decision dashboard built around the GM's actual recurring questions — where to add capacity, where marketing is working — rather than around the systems the data comes from. Sign-ups, service requests, and route loads join on neighborhood geography, each metric kept at its own grain so density questions get honest answers without flattening either team's view. Every tile carries its data's as-of date, because the dispatch export is weekly and pretending otherwise would poison trust on first contact. The dashboard is for the GM's decisions; drivers and dispatchers are not the audience and were not asked to become one.

Just as important is what we ruled out, and why:

• A field operations app that would capture data at the cab — Drivers and dispatchers will not use a dashboard, and a rollout that depends on their daily compliance would have failed before it started — the GM needed answers, not adoption.
• Investing in dispatch-system custom reporting modules — The dispatch vendor quoted per-module licensing and a quarterly release cycle, and even then the system would never see sign-ups or email requests — the join was the whole point.

How the work ran

Delivered by the growth pod — analytics specialist over 6 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

Looker Studio

One page per recurring decision, phone-readable in the yard office, and no seats to buy — the GM opens one link instead of assembling three screens.

BigQuery

The geographic join between three systems of different shapes needs a real warehouse; neighborhood keys are cleaned once there and never re-argued in a chart.

Weekly dispatch export

The dispatch system cannot be changed, so its weekly export is treated as fact and dated visibly — honest staleness instead of fake freshness.

Geographic join keys

A canonical neighborhood reference list fixes the freehand-naming problem at the root; every source maps to it on arrival, so spelling disputes end structurally.

GA4

Sign-up demand starts on the website, and the service-area pages' traffic adds the demand signal dispatch will never capture on its own.

What went wrong

How we worked together

Cadence

A 30-minute call each Thursday timed against the GM's Monday review, with the dashboard demoed on his actual questions; a written data-age note accompanied every weekly export.

Client side

The GM was the ultimate audience and set priorities by question; the office manager supplied dispatch exports and neighborhood knowledge; the marketing coordinator owned the website side.

Decisions

The GM decided what the dashboard must answer and in which order; grain and geography choices were settled with the office manager, who owns the underlying data day to day.

They provided

Weekly dispatch export access, the email service-request folder, sign-up records with addresses, and one honest hour weekly from the office manager on neighborhood naming.

What changed

The headline: gm's weekly review running from a single dashboard with explicit data ages — Three screens → one decision dashboard, read from GM review adoption. A second check: sign-up-to-route-density alignment in expansion neighborhoods at +19%.

The Monday review now starts from one page whose every tile says how old its data is, and the GM stopped reconstructing the week from screenshots beforehand. Capacity conversations gained a shared artifact: expansion neighborhoods are argued with sign-up curves against route loads, not with whoever speaks most confidently. The office manager stopped building her manual spreadsheet, and service-request pockets that used to surface as complaints now surface as tiles. The composting push got its first real demand map, which the GM had wanted for two years without a way to ask.

The result was read from GM review adoption against the pre-engagement baseline over the stated window, with a guardrail check on sign-up-to-route-density alignment in expansion neighborhoods. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• The decision dashboard organized around the GM's recurring questions, with as-of dates on every tile.
• The canonical neighborhood reference list with aliases, owned by the office manager.
• The BigQuery join pipeline with validation that refuses malformed dispatch exports.
• A weekly import checklist including the holiday-edge-case notes.
• The service-request tagging convention that keeps the email folder classifiable.