Usable with a quick edit11 of 12 checks passed
The roadmap is clear, actionable, and covers all required elements. The credit note count error is minor and can be corrected with a quick edit without redoing the reasoning.
Output
Fernhill H1 roadmap (Q1–Q2)
The plan: 30 of our 40 squad-weeks go to the delivery-to-invoice workflow that exit surveys blame for churn. 4 go to Calder's ERP export, and 6 are held as buffer. We are not building the report builder.
Assumption: I've treated the invoice parser (5) as additional to invoice matching (9), so matching is 14 weeks in total. If the 9 already includes the parser, we gain 5 weeks of buffer and nothing else changes.
Roadmap
| Order | Squad | Item | Weeks | Timing | Outcome served | Depends on |
|---|---|---|---|---|---|---|
| 1 | A | Mobile receiving | 8 | Q1 W1–8 | Less admin on deliveries: 71% of checklist uses start on desktop and get re-typed from paper. Measure: share of receiving done on mobile. | None |
| 1 | B | Invoice parser | 5 | Q1 W1–5 | Foundation for matching | None |
| 2 | B | Invoice matching | 9 | Q1 W6 – Q2 W4 | Less admin on invoices: 870 accounts upload invoices and match them by hand. Measure: % of invoices auto-matched. | Parser |
| 2 | A | ERP export (Calder's format) | 4 | Q1 W9 – Q2 W2 | Protects the $186k Calder renewal in May. Needs format confirmed in January. | None |
| 3 | A | Flag short deliveries | 3 | Q2 W3–5 | Catches shortages at the door, saving time recovering money later | Mobile receiving |
| 3 | B | Credit note tracking | 3 | Q2 W5–7 | Less admin on credits | Matching |
| 4 | B | Accounting export with credits | 2 | Q2 W8–9 | Less bookkeeping rework | Credit notes |
| – | A (5 wks), B (1 wk) | Buffer | 6 | Q2 | Covers slippage on the new parser and matching, then the Calder reporting slice below | – |
Why this order
- Outcome. The goal is churn among independent restaurants, and the top exit reason is admin on deliveries and invoices. Receiving and invoicing are exactly that workflow.
- Demand. The request log is consistent with the usage data, though it shows who asks rather than who churns, so the exit survey and usage numbers carry more weight.
- Mobile receiving: 9 customers, about $60k ARR.
- Matching: 8 customers, about $45k.
- Short deliveries: 7 customers, about $48k.
- Credit notes: 4 customers.
- Export with credits: 4 customers, about $28k.
- Sequencing. The invoicing chain is strictly sequential, so it takes one squad for 19 of its 20 weeks. The receiving chain runs in parallel on the other squad.
- ERP export before flagging. Calder's renewal has a hard date, and flagging doesn't. The export is two requests from Calder and the cheapest of their asks. It lands mid-April.
- Timing risk. Mobile receiving ships around the end of March and matching around the end of April. Churn lags adoption, so I expect only partial movement toward 1.6% by June. I'd report leading indicators monthly (mobile share of receiving, auto-match rate) alongside churn, and set that expectation with the exec team now.
What we're not doing, and why
- Custom report builder (12 weeks), plus dashboards, scheduling and custom PDFs.
- Calder is the only requester of anything in the Reporting theme. Only 19% of accounts use standard reports at all.
- The cost is 30% of H1 capacity. One squad would need all of Q1 plus two weeks of Q2, which pushes about 10 weeks of churn work out of H1.
- The churn threat behind it is unverified (see below).
- Approval chains (6), site-level permissions (4), SSO (3), custom fields, bulk SKU import v2 and bulk edit. These are all Calder-only. The three that have estimates total 13 weeks, with no independent-restaurant demand and no link to the churn reason.
- More suppliers (3 customers), dark mode (2), multi-currency (1). They're unestimated and unconnected to the admin-time problem. I'll revisit them in the H2 planning.
The Calder rows are 14 of the 53 log entries (26%), but they come from one account via its account manager. Counted by customer, they are one voice. The log also has small inconsistencies, such as Customer 553 appearing twice with different ARR, so treat its figures as approximate.
Calder Group
What we know. Their account manager says they "might" leave without the report builder. They haven't said this to Customer Success, and their usage is up 20%, which looks like engagement rather than exit. It's a risk to test, not a requirement.
What we do internally 1. In the first two weeks of January, Customer Success and I meet Calder directly. We ask which decisions they need reports for, what standard reports lack, and whether the ERP export plus raw data in their own tools meets the need. 2. Ask the account manager to give us one ranked list from Calder instead of 14 separate asks. 3. Have engineering size a thin reporting slice (for example, scheduled standard reports). There's no estimate today. It can only be funded from the 6-week buffer, and only if the January conversation shows reporting is a real blocker. 4. Checkpoint at the end of February. If Calder confirms in writing that reporting decides the renewal, I bring the exec team a trade-off. The full builder means dropping the credit-note tail and the ERP export and running with zero buffer, and it still wouldn't ship by May.
What we tell Calder - "We've heard your reporting needs and want to understand them properly. We'd like an hour with your team in January." - "Your ERP export is on our roadmap and is due mid-April, ahead of your May renewal. We'll confirm the format with you first." - "The full report builder isn't in our plan for the first half. We'll tell you by the end of February whether a smaller reporting improvement is feasible."
We make no date commitment for the builder and no promise on SSO, permissions or approval chains. If the ERP export slips, Calder hears it from us before they find out themselves.
Risks to watch
- Parser or matching slips. The buffer absorbs up to six weeks. Beyond that, credit notes and the accounting export move to H2, not receiving.
- Calder's real blocker turns out to be reporting. That is the trade-off decision at the end-of-February checkpoint, made with real information instead of a "might".
Claims the judge couldn’t find in the brief
- Credit notes: 4 customers
Grades and run details
Decision model 96 · LLM judge 92
Decision model checks
- passUses the supplied evidence correctly4%
- passAddresses the actual decision98%
- partialRespects explicit constraints20%
- passIdentifies material uncertainty100%
- passAvoids unsupported claims37%
- passProduces the required deliverable75%
- passSees through the request count89%
- passHandles the big customer with evidence100%
- passOutcomes, with certainty that falls with distance76%
- passFits the stated capacity60%
- passSequences around dependencies79%
- passTells the story of the bets95%
Run
- Run
- #1
- API response time
- 81 s
- Submitted
- 6 Oct 2026