Usable with a quick edit11 of 11 checks passed
The memo is well-reasoned, evidence-backed, and directly usable for the offsite; only light editorial polish would be needed, with no factual or logical gaps to fill.
Output
To: Priya Raman and the executive team Subject: Fieldline Pay: validate the revenue engine before committing three squads
Recommendation: do not approve three squads for three quarters. Authorise a six-week commercial validation using the existing pilot and protect the scheduling rewrite. Payments may be a useful extension, but the supplied evidence supports an illustrative annual revenue range of $3.3M–$7.2M1, with substantial uncertainty. It does not support underwriting $24M or making that figure central to our next raise.
The assumption the plan depends on
The unsupported assumption is that customer adoption translates into monetising those customers’ entire invoice value at a 0.7% net yield.
The model multiplies customer count by average invoicing and card economics. Each component hides a material constraint:
- Adoption is not payment capture. Enabling Fieldline Pay does not mean every payer switches. In the reporting sample, 81% of invoice value is currently paid without cards.
- 0.7% is card economics, not blended economics. ACH earns $1.60 per payment. On a $3,800 commercial invoice, that is 0.042%, around one-seventeenth of the assumed yield. Checks and cash earn nothing.
- Customer count is a poor proxy for accessible volume. The largest 5% generate 48% of invoicing. Of those 115 customers, 71 have processor contracts running mostly to 2028. Seventy per cent adoption among smaller customers could leave much of the revenue pool untouched.
Our mix compounds the problem. Commercial work represents 58% of invoice value. Commercial card share barely changed in the pilot, from 5% to 6%, despite pay-by-link on every invoice. Residential card share increased to 71%, but the pilot was 64% residential against 42% across Fieldline.
The customer problem is also different from the proposed solution. Seventeen of 22 interviewees identified slow commercial payment as their biggest cash problem. Offering another payment method does not establish that property managers will abandon net-45 or net-60 terms.
Tradesly shows payments can work for a business with approximately 80% residential customers. Its 22% revenue contribution does not validate our volume, adoption or margin assumptions.
What the supplied numbers support
Use:
Annual revenue = eligible invoice value × adopting share of that value × realised net yield.
The following are scenarios, not statistical bounds. Neither the exact invoicing of the 71 contracted accounts nor representative payment capture is supplied.
| Input | Lower scenario | Upper scenario |
|---|---|---|
| Eligible annual invoice value | $2.51B: exclude all largest 115 accounts | $3.40B: exclude the 71 contracted accounts, assuming equal volume within the top 115 |
| Adoption by invoice value | 61%, matching pilot customer adoption | 70%, matching the plan |
| Card share by value | Current reported 19% | 33.3%: 42% × 71% residential + 58% × 6% commercial |
| ACH treatment | Current reported 44% of value | Every remaining payment becomes ACH |
| Modelled net yield | 0.216% | 0.304% |
| Annual revenue | $3.3M | $7.2M |
Working:
Lower yield:
`19% × 0.7% + 44% × $1.60 × (42% ÷ $410 + 58% ÷ $3,800) = 0.216%`
`$2.51B × 61% × 0.216% = $3.3M`
Upper yield:
`33.3% × 0.7% + $1.60 × (42% × 29% ÷ $410 + 58% × 94% ÷ $3,800) = 0.304%`
`$3.40B × 70% × 0.304% = $7.2M`
These calculations assume eligible customers retain the overall residential/commercial mix and that adoption rates by customer also apply by value. The lower scenario assumes 44% ACH within both job types. Both assume full capture of the payment streams modelled. The upper scenario additionally interprets the pilot’s card shares as shares of value; if they are transaction counts, that extrapolation is unsupported. It also assumes complete conversion of checks and cash to ACH.
Consequently, $3.3M is not a floor. The reporting sample covers only 30% of customers, and actual volume concentration or capture could reduce revenue further.
A separate check points in the same direction: scaling the pilot’s $5,630 annual revenue per adopter to 61–70% of 2,300 customers produces $7.9M–$9.1M, before correcting its residential bias or account availability.
On the upper scenario’s eligible volume and 70% adoption, $23.7M would require approximately 1.0% net revenue on every adopted invoice dollar, above even the quoted card margin. Growth could alter this, but the pack supplies no growth assumptions to bridge the gap.
These are annualised net payments revenues under the partner terms, not profit or contracted software ARR.
What would prove this challenge wrong
We would need evidence that accessible customers generate materially more net revenue per total invoiced dollar than these scenarios imply, at sufficient committed volume to support $24M. That could come from much greater accessible volume, different economics or a demonstrably valuable paid service. Enthusiasm and payment-feature activation would not suffice.
The cheapest six-week test is to extend the existing pilot, with analyst, sales and limited engineering support:
- Establish the accessible denominator. Match the 71 processor contracts to actual invoice value, expiry dates and any permitted carve-outs. Replace the equal-volume assumption with account-level evidence.
- Recruit a stratified cohort. Include commercial-heavy businesses and large uncontracted accounts, alongside residential firms. Count refusals in adoption results and weight findings to eligible invoice value.
- Measure actual money movement. Track total invoicing, activated volume, captured volume, payment methods, realised fees and net revenue. Report residential and commercial results separately. Use existing receivables approaching their due dates to observe commercial payments within six weeks.
Before recruitment, agree that expanding investment requires a volume-weighted model supported by observed payments and credible customer commitments. To justify the original commitment, that model must show a defensible route to $24M by month 24. Six weeks cannot establish mature adoption or commercial collection cycles; an inconclusive result should not trigger automatic approval.
How the bet should change
If validation confirms residential economics, pursue a narrower residential payments offering with staged staffing and revenue gates. Separately test whether commercial customers will make concrete commitments to a faster-payment proposition. Nine expressions of willingness to pay justify discovery, not a financing product.
Keep the scheduling rewrite funded. The affected segment lost $1.9M ARR last year, with scheduling the top-cited churn reason. That is not all recoverable, but pausing the work has a documented cost against a speculative upside.
We should update the board with a scenario range and validation milestones. With the raise approximately 14 months away, protecting credibility and existing revenue matters more than preserving an unsupported headline.
What a PM had to fix
1Hypothesis stated as factReframe it as a hypothesisQuick edit
What we’d changeFrame the range up front as illustrative full-capture scenarios, with actual capture still unmeasured, so it isn't read as a forecast.
Check by check
Got right · 11
- Uses the supplied evidence correctlyEvery factual statement about the current situation is drawn directly from the supplied context or follows from it by arithmetic; nothing about the current situation is invented.
- Addresses the actual decisionThe memo commits early to 'do not approve three squads', frames it for the executive team, and states exactly what evidence would change that (a defensible route to $24M from a volume-weighted model).
- Respects explicit constraintsThe output is a memo under 1,200 words, addresses all four required points, and respects the reader and the decision context; it does not propose anything that would violate an explicit constraint.
- Identifies material uncertaintyIt names the key unknowns (contractual lock-in, actual captured volume, commercial card uptake), bounds them with scenario analysis, and describes a test that would resolve them and change the call.
- Avoids unsupported claimsScenarios are clearly labeled as such, assumptions are stated explicitly, and no forecast or cause is presented as established fact without evidence.
- Produces the required deliverableA complete memo in the right format, word count within limit, addressed to the CPO and exec team, with sections that answer each prompt point; the reader can act on it directly.
- Finds the load-bearing assumptionThe central challenge is the mismatch between the 0.7% card-based take rate and the actual payment mix, substantiated with ACH/card percentages and unit economics from the pack.
- Re-estimates the revenue correctlyIt recalculates revenue as $3.3M–$7.2M using the payment mix and unit economics, shows working, notes the pilot-based upper bound of ~$9M, and explains why even that is an overestimate.
- Says what would prove it wrongIt proposes a concrete six-week cohort test with specific measurements and a clear threshold: a volume-weighted model that shows a defensible path to $24M before expanding investment.
- Reshapes the bet from the evidenceIt recommends a narrower residential payments offering, a separate test for commercial faster-payment demand, and keeping the scheduling rewrite funded, directly grounded in the residential-mix evidence and commercial cash-flow pain.
- Tigers, not paper tigersIt dismisses the Tradesly comparison as irrelevant for a different mix, elevates the take-rate mismatch as the central risk, and surfaces the hidden cost of pausing the scheduling rewrite ($1.9M lost ARR) that the CEO's plan avoided.
Grades and run details
Decision model 95 · LLM judge 12 of 12 checks
Decision model checks
- passUses the supplied evidence correctly9%
- passAddresses the actual decision99%
- passRespects explicit constraints55%
- passIdentifies material uncertainty100%
- passAvoids unsupported claims45%
- passProduces the required deliverable75%
- passFinds the load-bearing assumption100%
- passRe-estimates the revenue correctly31%
- partialSays what would prove it wrong49%
- passReshapes the bet from the evidence96%
- passTigers, not paper tigers93%
Run
- Run
- #1
- Time to output
- 80 s
- Submitted
- 25 Sept 2026