Four charts and a finding are not an answer. Today we turn them into the one page the operations director takes to the board.
| Time | Segment | What Happens |
|---|---|---|
| 0–8 min | The gap | Why last week's dashboard is not yet an answer |
| 8–24 min | Cancellation deep-dive | Driver vs customer, and what a flat distribution means |
| 24–40 min | Interrogating 17:00 | Four attacks on our own finding, and whether it survives |
| 40–52 min | Geography | Pickup-point analysis; the hub concentration |
| 52–64 min | Story structure | Sequencing charts into an argument; the Z-pattern |
| 64–76 min | The memo | Action, impact, falsification — written live |
| 76–84 min | Limits | What this data cannot answer, and saying so well |
| 84–90 min | Wrap | Project brief preview; Assignment 3 clarifications |
You finished Lecture 15 with four correct charts and one genuine finding: the 17:00 failure rate. If you emailed that dashboard to the operations director right now, the reply would be one word — “And?”
That reply is the whole subject of this lecture. There are three distinct levels of analytical output, and most analysts stop one level too early:
| Level | What it sounds like | What the reader does |
|---|---|---|
| Description | “37.71% of bookings fail.” | Nods. Nothing changes. |
| Diagnosis | “Most failures are supply-side, and they concentrate at 17:00.” | Finds it interesting. Still nothing changes. |
| Recommendation | “Run a driver incentive at 16:30–17:30 in the top three hubs. Cost ₹X, recovers ₹Y, and we will know inside three weeks.” | Decides. |
The dashboard is the evidence, not the argument. Nobody ever acted on a chart. They act on a sentence containing a verb, and they trust it because a chart stands behind it. If your final slide has no verb, you have built evidence for a case nobody made.
So today's work is in two halves. First we go deeper into the data, because a recommendation needs more than one finding to stand on. Then we structure what we have into something a busy person can act on in ninety seconds.
We know 37.71% of bookings fail. “Reduce cancellations” is not actionable. Decompose it until it names someone who can do something.
| Outcome | Bookings | Share of all | Who can fix it |
|---|---|---|---|
| Cancelled by Driver | 2,698 | 17.99% | Supply team — incentives, allocation, penalties |
| No Driver Found | 1,036 | 6.91% | Supply team — fleet density |
| Cancelled by Customer | 1,022 | 6.81% | Product — ETA accuracy, pricing clarity |
| Incomplete | 901 | 6.01% | Operations — mid-trip failures |
Group the first two: 3,734 bookings, 24.89% of everything, fail because no driver completed the job. That is nearly four times the customer-cancellation rate. The problem now has an owner, and it is not the product team.
This is the single most valuable move in the analysis. “37.71% of bookings fail” is a statistic that belongs to nobody. “Roughly a quarter of all bookings fail on the supply side” names a department and a budget. Decomposition is how a number acquires an owner.
Chart 4 from last week gave us the driver reason codes:
| Driver reason | Count | Share of driver cancellations |
|---|---|---|
| Customer related issue | 729 | 27.02% |
| More than permitted people in there | 666 | 24.68% |
| Personal & Car related issues | 652 | 24.17% |
| The customer was coughing/sick | 651 | 24.13% |
Four reasons spanning less than three percentage points. There is no dominant cause, and a flat distribution like this has exactly two honest interpretations:
Interpretation two is almost certainly closer to the truth, and you can say so without overclaiming. “Three of the four leading driver-cancellation reasons attribute fault to the customer, in near-equal proportions. That pattern is more consistent with drivers selecting the lowest-penalty option than with a real distribution of causes. We should not design an intervention around these codes until they are validated.” That is a defensible paragraph, and it is far more useful than a bar chart of unreliable categories.
| Customer reason | Count | Share |
|---|---|---|
| Driver is not moving towards pickup location | 211 | 20.65% |
| AC is not working | 210 | 20.55% |
| Driver asked to cancel | 208 | 20.35% |
| Change of plans | 203 | 19.86% |
| Wrong Address | 190 | 18.59% |
This table contains the most important single row in the whole dataset. “Driver asked to cancel” — 208 bookings, 20.35% of customer cancellations.
Those are driver cancellations recorded as customer cancellations. The driver did not want the trip, asked the passenger to cancel so the penalty fell on them, and the data now attributes it to the customer. Add the 211 “driver is not moving towards pickup” — a strong signal of the same behaviour — and roughly 419 of 1,022 customer cancellations, 41%, are plausibly driver-initiated.
The supply-side share is therefore understated, not overstated. Our 24.89% figure was already the largest component. Reattributing those 419 bookings pushes it toward 27.6%, and it means the customer-cancellation number — the one that looks like a product problem — is substantially a supply problem wearing a disguise. Always look for the category that is absorbing another category's failures.
The 17:00 result is the centrepiece of the recommendation, which means it has to survive being attacked. Do that yourself, in private, before someone does it to you in a board meeting.
Fair question, and it is exactly the trap that catches 03:00 with its 43.48% on 46 bookings. But 17:00 carries 1,062 bookings. At that volume the rate is stable to within a fraction of a percentage point. Survives.
The honest answer is that it is a 2.78 percentage-point gap — a 7.5% relative increase in failure rate. Across 1,062 bookings that is roughly 30 additional failed trips in that hour alone, or about ₹7,000 of fares. Over a year it is material; in any single hour it is modest.
Partially survives. The right framing is not “17:00 is catastrophic” but “17:00 is where the failure rate peaks, and it is the leading edge of the evening block where volume is highest.” The intervention should target 16:00–18:00 as a window, not 17:00 as a point — 16:00 fails at 40.45%, which strengthens rather than weakens the pattern.
Noticing that 16:00 fails at 40.45% is what turns a point into a trend. One anomalous hour is a curiosity. Two consecutive hours of elevated failure immediately before the demand peak is a mechanism: drivers have not yet repositioned for the evening rush. The second data point is what makes the story credible.
A real concern. If 17:00 happens to carry a disproportionate share of airport trips, and airport trips fail more often, then the hour is innocent and we would be fixing the wrong variable. Test it by segmenting the 17:00 bookings by vehicle type and pickup location and comparing against the daily mix. If the composition matches but the rate differs, time is the driver. This is the check that separates a finding from a coincidence, and it is the kind of work the project rubric rewards.
Always have an answer. Ours: if driver log-in data showed the same number of active drivers at 16:00–17:00 as at 18:00, our repositioning explanation collapses and we would need a different mechanism. We do not have driver supply data — and saying that plainly is a strength, not a weakness. It tells the reader exactly which additional dataset would resolve the question.
Time tells you when to intervene. Location tells you where. Together they make an intervention small enough to be affordable.
| Pickup location | Bookings | Cancelled | Cancellation rate | Revenue |
|---|---|---|---|---|
| Noida Sector 62 | 1,209 | 405 | 33.50% | ₹1,82,078 |
| Indira Gandhi International Airport | 1,183 | 388 | 32.80% | ₹2,04,445 |
| New Delhi Railway Station | 1,179 | 391 | 33.16% | — |
| Gurgaon Cyber City | 1,178 | 368 | 31.24% | — |
| Connaught Place | 1,139 | 374 | 32.84% | — |
Two things stand out, and the second is easy to miss.
First: the top five are all transport or office hubs — an office cluster, an airport, a railway station, a business district and a city centre. They account for 5,888 bookings, 39% of all demand, concentrated in five places. Anything you do at those five locations reaches four bookings in ten.
Second: the cancellation rates are remarkably similar — 31.24% to 33.50%, a spread of barely two points. There is no catastrophic location. This is genuinely useful because it rules something out: the problem is systemic, not local. A fix aimed at one bad hub would not work, because there is no bad hub.
A flat distribution is a finding when it rules out a hypothesis. “We checked whether specific locations drive the failures. They do not — the spread across the top five is two percentage points. This is a system-wide supply problem, so the intervention has to be system-wide or time-based rather than site-specific.” That paragraph does real work, and it comes from a chart that looks boring.
Combine the two dimensions and the intervention sharpens considerably: not “fix cancellations”, but “target the 16:00–18:00 window at the five hubs that carry 39% of demand” — a defined, costable, measurable action.
You now have five findings. Presented in the order you discovered them, they are a lab notebook. Presented in the right order, they are an argument.
The stake. 37.71% of bookings fail; up to ₹13.3 lakh of annual revenue at risk. Establish that the problem is worth the room's attention.
The narrowing. Roughly a quarter of all bookings fail on the supply side — and reattributing “driver asked to cancel” pushes that higher. This is not a demand problem. The problem now has an owner.
The mechanism. Failures peak at 16:00–17:00, immediately before the 18:00 demand peak, which is consistent with drivers not yet having repositioned. This is the insight the audience did not have.
The target. Five hubs carry 39% of demand with uniform cancellation rates — so the intervention is time-based and system-wide, concentrated where volume already is.
The action. One recommendation, costed, with an expected impact and a date by which you will know whether it worked.
The limits. What this analysis cannot establish, and what data would close the gap. Placed last so it qualifies the recommendation without burying it.
Readers scan a dashboard in a Z: top-left, top-right, bottom-left, bottom-right. Put the stake top-left, the mechanism top-right, and the supporting detail below. A chart placed bottom-right is the last thing read and the first thing ignored — never put your key finding there.
Three formatting rules that do most of the work. Every title states its question and its population. Every axis carries its unit. Every number on the page can be traced to a pipeline you can run on request. Charts that meet those three rules survive scrutiny; charts that do not get argued about instead of acted on.
This is the deliverable. The dashboard is the appendix.
Ride Completion — Recommendation
Finding. 5,657 of 15,000 bookings in 2024 (37.71%) did not carry a passenger, against realised revenue of ₹22.0 lakh. At the average completed fare of ₹235.73 this represents up to ₹13.3 lakh of forgone revenue — an upper bound, since some customers rebooked successfully.
Diagnosis. At least 24.89% of all bookings (3,734) fail on the supply side: driver cancellations plus no-driver-found. A further 419 customer cancellations cite “driver asked to cancel” or “driver not moving towards pickup”, which are plausibly driver-initiated, taking the supply-side share toward 27.6%. Customer-initiated cancellation is a minority of the problem.
Mechanism. Failure rates peak at 16:00 (40.45%) and 17:00 (39.92%), above the 18:00 demand peak's 37.14% despite 18:00 carrying more bookings. Supply appears to lag demand by one to two hours as drivers reposition for the evening.
Recommendation. Pilot a time-boxed driver incentive from 16:00 to 18:00 at the five highest-volume pickup hubs, which together carry 39% of demand. Size the incentive below the ₹235.73 average fare so the economics hold at any recovery rate above break-even.
Expected impact. Closing the 16:00–17:00 gap to the 18:00 baseline would recover roughly 60 trips per day across the two hours, approximately ₹14,000 daily or ₹51 lakh annualised at current volumes — before incentive cost.
How we will know. Compare the 16:00–18:00 failure rate at pilot hubs against non-pilot hubs over three weeks. If the gap does not close by at least one percentage point, the repositioning explanation is wrong and we stop.
What this cannot tell us. We have no driver log-in or location data, so the repositioning mechanism is inferred, not observed. Driver-reported cancellation reasons are unreliable — three of the four leading codes attribute fault to the customer in near-equal proportions, which is more consistent with penalty-avoidance than with a real distribution of causes.
Analysts under-report limitations because they fear it weakens the case. In practice the opposite happens: the reader who finds an unacknowledged limitation stops trusting everything else on the page.
| Limitation | Weak phrasing | Strong phrasing |
|---|---|---|
| No driver supply data | “More data would help.” | “We infer repositioning from the demand side. Driver log-in timestamps would confirm or kill it in a day.” |
| Unreliable reason codes | “The reasons are unclear.” | “Three of four leading driver reasons blame the customer in near-equal shares — a pattern more consistent with penalty-avoidance than with real causes.” |
| Lost-revenue estimate | “This is approximate.” | “₹13.3 lakh is an upper bound assuming no rebooking. The true figure is lower; the conclusion holds even if it is half.” |
| One year of data | “Limited time range.” | “2024 only, so we cannot separate a structural pattern from a one-year anomaly. The pattern is present in all twelve months, which argues for structural.” |
| Correlation only | “Causation unproven.” | “The pilot is the experiment. That is why we propose testing it on a subset rather than rolling it out.” |
The pattern in the strong column: name the specific gap, state what would close it, and say whether the conclusion survives. A limitation handled that way adds authority, because it demonstrates you went looking for the weaknesses yourself.
Add the pickup-location chart. Horizontal bar, route.pickup on Y, COUNT on X, sorted descending, limited to 10. Add a second value showing cancellation rate so volume and risk sit side by side.
Add the customer-reason chart and find “Driver asked to cancel” yourself. Confirm the 208 figure in mongosh before you build anything on it:
db.rides.countDocuments({
"cancellation.by": "customer",
"cancellation.reason": "Driver asked to cancel"
})Run the composition check from Attack 3. Group 17:00 bookings by vehicle_type and compare the mix against the full day. If the mixes match, time is the driver and your finding holds.
Re-sequence the dashboard into the six-step order from Section 5. Move charts physically. The stake goes top-left; the 16:00–18:00 mechanism goes top-right.
Retitle every chart as a question with its population stated. “Status” becomes “How do bookings end? (All 15,000 bookings, 2024)”.
Write your own one-page memo. Use the Section 6 structure but reach your own recommendation — you may well disagree with the incentive pilot, and a well-argued alternative scores higher than a copy. This is Assignment 3.
Have a classmate attack it. Give them five minutes and ask for the weakest number on the page. Whatever they find is what the marker will find.
Check your build against the reference. The Atlas Charts build guide lists the numbers your charts should land on — 9,343 completed, a 1,373-booking peak at 18:00, 17:00 top of the volume-floor ranking — along with the seven mistakes that most often make a dashboard look right and read wrong.
This dashboard recomputes its aggregations every time someone opens it — fine for a weekly review, hopeless for a wall-mounted operations screen refreshing every second. Next module we meet the opposite architecture: compute at write time, read in constant time. Same business questions, a completely different engineering trade.