What happened to the package, as opposed to how the van was driven. Four numbers decide something — POD, CDF, DSB and DC DPMO — and four more sit on the Scorecard doing nothing at all. Two of the four live ones are the only rungs on the whole ladder that a person still has to work by hand.
The share of eligible deliveries that got a usable photo. A settled exclusion with no research step: under the line, no bonus.
| Value | Result |
|---|---|
| < 98.0% | Ineligible |
| ≥ 98.0% | Passes this rung |
POD Opps. sits beside it on the Scorecard — the count of deliveries where a photo was actually possible, i.e. the denominator. It carries no rule; it is context for reading the rate, nothing more. A driver with a handful of opportunities can swing several points on one miss, which is worth knowing before anyone reacts to the percentage.
Over 3000 is the trigger, but it is not the verdict. A high DC DPMO on its own never tells the whole story — the number can spike off a single erroneous or out-of-their-control package. So the rule asks a second question: of that driver's exceptions that week, how many were not SIM'able, i.e. genuinely DA-controllable coaching opportunities?
| DC DPMO | Non-SIM'able TBAs that week | Result |
|---|---|---|
| ≤ 3000 | — | Passes this rung |
| > 3000 | > 1 | Ineligible — real controllable failures |
| > 3000 | 0 or 1 | Cleared — it was SIM'able, outside their control |
| > 3000 | no SIM data for that station/week | Exclusion stands |
The full treatment of that gate — including why the DPMO is gated rather than recalculated, and the three different ways "we couldn't check" can happen — is on the Defects page, which is where the SIM'able data itself is described.
Customers rating the delivery. Reported as a DPMO, rung 9 of ten, and one of the two rungs that still needs a person.
| State | Test | Result |
|---|---|---|
| Research not done | Raw CDF DPMO > 1822 and implied bad surveys > 1 | Flagged for research |
| Research not done | Either test fails | Passes this rung |
| Research done | Adjusted DPMO ≥ 1822 | Ineligible |
| Research done | Adjusted DPMO < 1822 | Cleared, eligible |
The implied-survey filter is the reason the flag list stays workable. A DPMO is a rate, so a single bad survey on a low-volume driver can spike it past 1822 on its own. Requiring more than one implied bad survey stops that one survey generating a research job.
The research itself: look the driver's actual feedback events up in Cortex, decide which are genuinely DA-controllable, and recompute the adjusted DPMO. Roughly 9 drivers per station-week reach this rung — measured, not estimated: W33 → 8, W34 → 18, W35 → 9, W36 → 9, DII5 W36 → 1. An earlier "~6 per week" figure was wrong.
Rung 10, the last one, and the other rung that needs a person. The trigger is blunt: DSB Count > 0 flags for research. Because the threshold is a count rather than a rate cutoff, the adjusted figure is simply the DA-controllable event count — any DA-controllable event excludes, zero clears.
Dan's call, 2026-09-20: DSB Count over zero gets researched, not auto-excluded.
Cortex → Performance → Quality → the week → Delivery Success Behaviors → click the count.
Only the Impacting events matter. Everything else on that screen is out of scope. These are the real Cortex column names:
| Cortex column | Bucket |
|---|---|
| Simul. Deliveries | DA-controllable |
| Delivered > 50 m | DA-controllable |
| No POD on Delivery | DA-controllable |
| Incorrect Scan Usage — Attended Delivery | Split by Dropoff Location — see below |
| Incorrect Scan Usage — Unattended Delivery | Dan reviews each one. Rare; never auto-excludes |
| Scanned — Not Delivered — Not Returned | A missing package — Slack lookup, then a draft to Jaimee and Dan |
Dropoff Location appears only in the per-TBA "Delivery contrast map"
modal, never in the table — so an Attended Delivery row cannot be bucketed from the list view
alone:
| Value | Bucket |
|---|---|
| DELIVERED_TO_HOUSEHOLD_MEMBER | DA-controllable |
| DELIVERED_TO_CUSTOMER | DA-controllable |
| DELIVERED_TO_RECEPTIONIST | not DA-controllable |
| DELIVERED_TO_MAILROOM | not DA-controllable |
| anything else | unknown → ask Dan, never guess |
The logic behind that split: handing the package to someone at the house is the DA's own choice. Handing it to a receptionist or a mailroom is how that building works, and is not on them.
Both leave the driver flagged — and the workbook will not build — until resolved:
One shortcut that saves real work: if the driver already has a DA-controllable event they are Ineligible either way, so neither pending item blocks the bonus decision. The missing package still deserves the email.
A research flag is only ever raised for a driver who has already passed rungs 1–8. So when a name lands on the research list, that flag is the only thing between them and the bonus. That is both why the list stays short enough to work by hand, and why skipping it pays the bonus by default.
| Column | Status |
|---|---|
| Delivered | Helper only — the denominator used to work out how many bad surveys a DPMO implies. |
| DSB | No rule. It is the column-alignment check: it should equal DSB Count / Delivered × 1,000,000. If the PDF were read out of alignment, that identity breaks across the whole sheet at once. |
| PSB | Nothing. Amazon shows "Coming Soon". |
| POD Opps. | Nothing. Context only. |
Of the 15 columns Amazon gives per driver: 10 drive a decision, 4 do nothing at all, and 1 is only a helper.
rules.py (POD_MIN, CDF_DPMO_MAX,
CDF_IMPLIED_MIN, DSB_COUNT_MAX, DC_DPMO_MAX).
DSB buckets and Cortex column names from
references/ripple-bonus-rules-at-a-glance.md. Last checked 2026-09-20.