How do you track and improve productivity in a car wash?
As part of my Australian adventure I picked up a job as a Vehicle Service Agent at a rental company — making sure every car is spotless and ready before a client drives away. Simple enough objective: 20 cars per shift. Harder than it sounds. I kept missing the target and had no idea why, so I did what any data person would do — I built a system to find out.
Executive Briefing
This briefing reports the findings of an 8-shift task-level time-tracking trial conducted from 16 to 26 March 2026. A single wash worker operates a single-bay car wash with a target of 20 cars per shift.
Task-level logs (Wash, Photo, Run, Walk, Setup/Clean, Fuel, Other) were cleaned (1 orphan row excluded, 1 corrupted timestamp repaired) and then aggregated to per-shift level. Throughput is unique CarIDs per shift. Time allocation is summed minutes per task. The Run-vs-throughput relationship was tested with a simple OLS trend across the 8 shifts.
The wash worker is averaging 15.1 cars per shift against a target of 20. The main cause is Running — taking cars from the photo area to the customer pickup area and back — which consumes an average of 29.6% of all logged time. By the rules of the business, this activity should be performed by a dedicated runner; the wash team should only cover it in exceptional cases.
Run time and throughput are inversely correlated across all eight shifts. The lowest-Run shift hits the target at 22 cars. The highest-Run shift produces only 11 cars.
The objective was clear. The data wasn't.
The workflow on the ground for a wash person starts by fetching a car from a queue in front of their bay. They can choose to work on one car or two at the same time — for the purposes of this analysis we made sure to work on just one at a time. The process then goes: interior cleaning, through the exterior cleaning machine, park in the photo area, take photos, and walk back to the bay to start all over again.
Every time a car is brought into a bay it gets logged on a paper worksheet — just the car ID and some basic data. That worksheet only tells you how many cars and what type were washed in a shift. If we were going to understand where the time was actually going, we needed a more precise way of measuring it.
The simplest solution I could think of: build an AppSheet app to log time against specific activities, store the data in Google Sheets, analyse it in Python, and visualise it in a Looker Studio dashboard.
Building a data collection system from scratch.
The solution was a custom AppSheet application connected to Google Sheets. Workers log every task in real time — tapping a task type, selecting a car ID, and saving. AppSheet timestamps each entry automatically, which means the raw material for time analysis is captured without any manual effort from the team.
The app tracks eight task categories:
The app was designed for speed — workers can log a task in under 10 seconds. The main view shows active tasks; tapping any action button opens a form pre-filled with the task type. Car ID, car type, and optional notes are the only required fields.
What the data revealed.
Mean throughput across all eight shifts was 15.1 cars, the median 14.5, but the most interesting value is the range: from 11 to 22 cars. That range is the most important signal in the dataset — it tells us the process is capable of 22 cars, but on bad days it produces barely half of that. Something is making it less efficient depending on the day.
Looking at the chart, the days with the least throughput are also the days with the longest Run time. That's the first alarm: Run time is affecting the objective.
Based on the signal from Finding 01, the next question was: where is the wash worker actually spending their time? The data showed that 57.4% of all logged time went to the actual wash process, and 29.6% went to Running — moving cars between the photo area and the customer pickup zone. Together, these two activities consume around 87% of all logged time.
With the ultimate goal of cleaning 20 cars per shift in mind, we can classify these activities into two groups:
Activities directly related to cleaning the car — Wash, Photo. These contribute directly to the objective.
Activities not directly related to cleaning the car but necessary for the process — Setup/Clean, Fuel.
Activities that consume time without contributing to cleaning — Run, Walk, Other. Run alone accounts for nearly a third of all logged time.
All findings point in the same direction: Run time is the key predictor of throughput in this dataset. To characterise the relationship, an OLS trend was fitted across all eight shifts. The result was a slope of -0.038 cars per Run-minute — meaning the process loses one car for every 26 minutes spent Running.
The practical impact is clear: on the shift where Run time reached 239 minutes, the model predicts — and the data confirms — a loss of roughly 9 cars compared to a low-Run shift. The scatter plot shows the trend is not a statistical artefact; every single shift follows it in the same direction.
One hypothesis raised by the team was that not all car types take the same time to clean, and that this could be limiting throughput on certain shifts. To test this, wash duration was broken down by car type.
The data shows median wash time sits between 9 and 13 minutes across all vehicle classes — a narrow range with no obvious outlier, except for V (12-seater vans) which sit slightly higher. There is a less-than-ideal spread within each category, but this is most likely attributable to how dirty a car arrives rather than the car type itself — a variable that wasn't measured in this trial but would be a valuable addition to future data collection.
The conclusion: car type is not a meaningful driver of throughput variation. The constraint lies elsewhere.
Currently, one in every three minutes of the wash worker's logged time is spent Running. This is not an efficiency problem inside the wash process — it is a staffing allocation problem at the team level.
To quantify the impact, three scenarios were simulated for each of the eight shifts:
These projections do not account for the additional gains from eliminating context-switching during the shift — the mental and physical cost of switching between Running and washing. In practice, the throughput improvement could be even greater.
Controlling Run Time
The main conclusion of this analysis is that Run time is the primary driver of missed throughput targets. On days where Run time was high, car throughput fell — these two variables have a direct, consistent relationship across all eight shifts in the dataset.
From operational knowledge, we know that the number of cars rented on any given day doesn't always justify having a dedicated full-time runner. So rather than a binary "runner or no runner" recommendation, the data allows for a more nuanced target: analysing the dataset, a wash worker can allocate up to 70 minutes to Running and still reach 20 cars per shift. This is based on mean data only and does not account for which car types are being cleaned or the level of dirt in each one — both variables that could refine this threshold further.
The dashboard translated this into a concrete operational target: keep Run time under 69.5 minutes per shift. That's the number the team can now monitor daily, without needing to understand the underlying math.
Live Dashboard
One advantage of having the data online is that you can build a dashboard to monitor the operation in real time. That's exactly what was built using Looker Studio — a deliberately simple design that gives a manager or supervisor a quick read on what's happening, with visual cues in red, yellow, and green.
The main KPIs on the first page are: number of cars cleaned, average wash time, cars per wash hour (how many cars the worker completes per hour of active washing), cars per active hour (accounting for the full shift), and wash activity breakdown. The bottom half gives a deeper view of the efficiency gap, with Run time as the headline metric. The second page offers a more operational analysis designed to surface trends over time.
What this project demonstrates.
The real skill here isn't Looker Studio or AppSheet — it's the problem decomposition. The business had a productivity problem. Before any analysis was possible, a data collection problem had to be solved first. That meant designing a tool people would actually use under time pressure, in a physical environment, with minimal friction.
The insight that emerged — a specific, actionable Run time threshold — didn't require sophisticated modelling. It required clean data and the right question. The dashboard makes that insight persistent and self-serve, so the team doesn't need an analyst to tell them whether they're on track each shift.
That's the pattern that transfers to any operations role: identify the constraint, quantify it, and make the answer visible to the people who can act on it.