Forecast · next week · Jun 15 – Jun 21
7–14
Central estimate10
red plates expected next week
Based on trailing 4-week average (8.8) + linear trend (slope +0.3/wk) + this week's pace (6 so far through day 3 of 7).
6
This week so far
Jun 08 – today · day 3 of 7
10
Last completed week
Jun 01 – Jun 07
8.8
Trailing 4-wk avg
min 7 · max 10
51
Total since launch
Apr 20 onward
Weekly History
Red plates approved (solid bars) vs red-plate emails sent that week (light bars · leading indicator).
Red plates approved · PLATE_PHOTO with status=APPROVED
Red-plate emails sent · application to Zulassungsstelle
Pipeline Pressure · Leading Indicators
Where drivers are stuck right now, in order of "closeness to red plates". Top of list feeds the weeks ahead; bottom feeds next week.
Selected insurance · no eVB
367
Picked an insurance option in-app but hasn't gotten/uploaded an eVB number from an insurer. Biggest funnel leak — only ~35% of these progress.
eVB uploaded · no email yet
67
Driver has the eVB number on file. Ops can send the red-plate email to the Zulassungsstelle. Usually fast.
Email sent · awaiting plates
185
Red-plate email sent to Zulassungsstelle. These are the ones we expect to see plate-photo uploads from next.
The Funnel
Where 10,443 signups have ended up. Biggest leak: 43% of drivers who pick an insurance option actually get an eVB number from an insurer.
10,443
Signups
85 in last 7d
→ 8.5%
884
Führungszeugnis + GZR
both uploaded
→ 74.4%
658
Gewerbeanmeldung
Gewerbeschein uploaded
→ 102.0%
671
Insurance selected
radio click in-app
→ 42.9%
288
eVB uploaded
got number from insurer
→ 72.6%*
209*
Red-plate email sent
185 awaiting plates · see note
→ 24.4%
51
Red plates received
0.49% of signups
*Red-plate email caveat: the redPlatesEmailSentAt field has only
been populated since Apr 29, 2026 (21 days). Of the 51 drivers who already
received plates, only 4 have this field set — the other 18 went through an older manual
process that didn't populate it. So 209 is the count of
trackably-emailed drivers, not all drivers ever emailed. The forecast itself uses
plate-photo uploads as the signal so it isn't affected by this gap.
eVB approval: a separate back-office verification — not a gate. Of the
209 emails sent, only 110 had APPROVED eVB at email time;
the other 99 were sent on UPLOADED status (ops trusts the upload and
approves later).
The Funnel · By Signup Cohort
Each row = drivers who signed up that week. Cells show how many have reached each stage and what % of the cohort that is. Older cohorts have had more time to convert — recent weeks are still maturing.
| Signup week |
Signups |
FZ + GZR |
Gewerbe |
Insurance |
eVB |
Email |
Plates |
| Jun 08this wk · | 34 | 25.9% | 12.9% | 12.9% | 00.0% | 00.0% | 00.0% |
| Jun 011w ago · | 443 | 235.2% | 184.1% | 214.7% | 30.7% | 30.7% | 00.0% |
| May 252w ago · | 1,131 | 716.3% | 484.2% | 544.8% | 151.3% | 111.0% | 00.0% |
| May 183w ago · | 1,238 | 1018.2% | 836.7% | 998.0% | 282.3% | 272.2% | 30.2% |
| May 114w ago · | 1,855 | 1035.6% | 774.2% | 925.0% | 321.7% | 291.6% | 20.1% |
| May 045w ago · | 1,873 | 1387.4% | 1105.9% | 1266.7% | 442.3% | 412.2% | 50.3% |
| Apr 276w ago | 1,101 | 1029.3% | 787.1% | 827.4% | 423.8% | 312.8% | 60.5% |
| Apr 207w ago | 866 | 869.9% | 778.9% | 859.8% | 414.7% | 283.2% | 101.2% |
| Apr 138w ago | 908 | 10211.2% | 687.5% | 495.4% | 384.2% | 161.8% | 141.5% |
| Apr 069w ago | 681 | 9714.2% | 7110.4% | 476.9% | 304.4% | 192.8% | 81.2% |
| Mar 3010w ago | 313 | 5918.8% | 278.6% | 154.8% | 154.8% | 41.3% | 31.0% |
How to read: darker red = higher conversion to that stage. Each column is
colored on its own scale (so eVB conversion in May is comparable to eVB conversion in April —
not to FZ+GZR conversion). A "·" next to the cohort age means it hasn't had enough time
to fully mature (typically takes ~6 weeks for plates to come through).
Insurance Pool · By Age
434 drivers finished insurance but haven't sent the red-plate email yet. Older entries convert less often.
| Days since insurance done |
Drivers |
% of pool |
| 0–6 days · fresh | 67 | 15% |
| 7–13 days | 68 | 16% |
| 14–20 days | 43 | 10% |
| 21+ days · stale | 244 | 56% |
How the forecast works
Plain-English explanation of the math behind the 7–14 headline.
The basic idea. We look at the past in three different ways and blend them.
No single view is right on its own — a flat average misses the trend, a pure trend
overreacts, and today's pace is noisy. Mixing them produces something steadier than any one
of them alone.
-
"How many do we usually get?"
Average of the last 4 completed weeks — the baseline.
Stable, but slow to react to change.
9 + 9 + 7 + 10 ÷ 4 = 8.8
-
"Which direction are we going?"
Draw a line through the same 4 weeks, then extend it one
week forward. Captures whether we're growing or shrinking.
10 + slope (+0.3/wk) = 10.3
-
"How are we pacing right now?"
This week's count so far, scaled to a full 7-day week.
Freshest signal, but 3 days into the week is noisy.
6 × 7 ÷ 3 = 14.0
The blend — weighted 40 / 40 / 20:
0.4 × 8.8 +
0.4 × 10.3 +
0.2 × 14.0
= 10.4
→ central 10
Why 40/40/20? Trust trailing average and trend equally; lean less on
this week because one Wednesday isn't a full week of evidence.
The range (7 – 14): roughly ±35% around the central
estimate, but never below half of last week's actual (10). This says
"if recent weeks keep behaving like they have been, expect around 10 —
with normal week-to-week variance, anywhere from 7 to 14".
Why this is useful
- Sets a defensible expectation for HQ. "We expect 7–14
next week" beats guessing.
- Acts as an early-warning baseline. If Friday's count is far below
7, something has broken (Zulassungsstelle delay, ops backlog, etc.) before
you'd otherwise notice.
- Shows which lever is moving. Trailing avg flat but trend up? Growth is
recent. Pace ahead of trend? Big week incoming. Each input tells you something different.
What it doesn't do
- Doesn't use the funnel directly. 35 emails went to the Zulassungsstelle
last week — those will land in the forecast only once plates start arriving (visible in
this-week pace or next week's trend).
- Doesn't know about external events. A Zulassungsstelle holiday, a system
outage, or a sudden capacity change in ops won't be reflected until it shows up in the data.
- Forecast horizon is 1 week. Extending further out compounds noise —
this gets unreliable beyond a week.
Signal definition
A driver "got red plates" on the day they uploaded their PLATE_PHOTO document
(only counted once ops eventually marks it APPROVED). This is the same definition
used by the existing bahn-onboarding-dashboard. The upload date represents when the driver
physically received the plates; the approval date is a back-office event that lags 0–3 days,
so we use upload date as the truer "plates received" timestamp.
Assumptions
Everything baked into the 7–14 number. If one breaks, the forecast misses.
Signal — how we count plates
- Upload date = pickup date. We assume the driver uploads the photo the same day
they pick up plates from the Zulassungsstelle. If they upload a day or two later, our
"current week" count is artificially low and the forecast underestimates.
- Only APPROVED photos count. An uploaded photo that's still PENDING / UPLOADED
review isn't included until ops approves it. Mid-week counts can creep up as approval
catches up to uploads.
- Rejection is rare. Historically only 1 out of 52 plate photos was rejected.
We treat rejection as effectively zero — if rejections start happening, the forecast
will overcount.
- Week boundary = Monday–Sunday. Postgres default. Same as the existing
bahn-onboarding-dashboard.
Math — how we extrapolate
- Past 4 weeks predict next week. The biggest assumption. We use only the last
4 completed weeks — older data is ignored. If something fundamentally shifts (new policy,
capacity boost, slowdown), the model takes 2–3 weeks to catch up.
- Trend is linear. We draw a straight line through 4 weeks and extend it one
week forward. Reality could be exponential (pipeline ramping up) or capacity-capped
(Zulassungsstelle at its limit) — both would break linear extrapolation.
- This-week pace scales uniformly. If we have 6 by day 3,
we extrapolate to ~14 for the full 7 days. In reality plates come in mostly
Mon–Fri, so this extrapolation can overshoot.
- Blend weights 40 / 40 / 20. Trailing avg, trend, and pace are weighted by
judgment, not by statistical optimization. Different weights would produce a different
central estimate — not by a lot, but enough to nudge the range.
- ±35% range. The lo/hi band is picked as a reasonable uncertainty band, not
derived from historical variance. A more rigorous approach would compute actual prediction
intervals once we have more data.
- Floor at ½ of last week. The lower bound never drops below half of last
completed week (10 ÷ 2 = 5). Arbitrary anchor to prevent
unreasonable pessimism when the central estimate is small.
Domain — what could break it
- No external shocks. Zulassungsstelle public holidays, system outages,
regulatory changes, or ops capacity changes aren't modeled. You'd need to manually
discount in those weeks.
- Driver behavior is stable. Drivers continue to upload plate photos at the
same pace and quality as before. A communications change or onboarding flow tweak
could shift this.
- Pipeline → plates conversion is stable. The forecast doesn't use upstream
funnel counts (insurance pool, applications in flight). It assumes the conversion from
application to plate is steady. If conversion shifts (better insurance support → more
applications → more plates), the model lags 1–2 weeks.
- Forecast horizon is one week. Extending further out compounds noise. Use
this number for next week. For 2-week or monthly planning, use the trend line directly
plus your judgment.
- Database is up-to-date. Queries hit the AWS read replica with seconds of
lag. If replication breaks, numbers stop updating.