What changed
FACT (cited): A federal Medicaid work-reporting rule is moving toward nationwide rollout, forcing enrollees to periodically document work or an exemption or lose coverage. HYPOTHESIS: the dominant second-order effect is mass PROCEDURAL disenrollment of still-eligible members who simply miss the recurring form — a pattern well-documented from Arkansas's 2018 work-requirement pilot, though that specific precedent is not in the provided sources.
Why now
FACT (cited): The rule is imminent and nationwide (NationofChange, Georgetown, HME Business on the interim final rule). INFERENCE: MCOs are paid per-member capitation, so each procedurally-churned member is a direct revenue loss, creating a fresh, quantifiable pain the moment the rule bites.
Converging signals
A regulation (work-reporting mandate) + a productized human-in-the-loop multi-channel messaging capability (eve chat SDK) + a payer-API interoperability push. The non-obvious flip is customer identity: not the enrollee (can't pay), not the state (adversary of retention), but the MCO whose margin the rule threatens.
Customer pain
INFERENCE, not yet evidenced with MCO-specific complaints: plans lose capitation on every churned-but-eligible member and want to protect their risk pool. This is plausible economics but the input contains ZERO demand_evidence from MCOs themselves — the FORCED-BUYER items are enrollee/advocacy-side, not buyer-side. The forced buyer here is the ENROLLEE, who is not who pays.
Who pays
Medicaid MCOs / CHIP / Medicare Advantage plans, on per-retained-member or SaaS terms. This is the core problem: the buyer is a regulated health-insurance enterprise, not a reachable prosumer or SMB.
Solved today
States and MCOs use their own member-outreach/care-management vendors, mailed notices, and call centers; large plans already run member-engagement platforms (mPulse, Icario/Revel, Gaine, HealthCrowd).
Why current solutions are bad
Legacy outreach is generic and low-response; it doesn't pre-fill the state filing or close the loop with proof. But incumbents already own the channel and the plan relationships.
Proposed product
A retention agent: multi-channel (SMS/WhatsApp/email) reminders keyed to each member's reporting deadline, guided proof collection, and a human-approved pre-filled state submission, dashboarded for the plan's retention team.
MVP version
A single-state pilot: ingest a plan's member list + reporting deadlines, run reminder cadences via the eve chat SDK, collect proof docs, and generate a pre-filled state form for human review. HIPAA-grade hosting from day one.
30-day build
Map 2-3 states' actual work-reporting submission portals/forms; build the reminder + proof-collection flow; stand up a BAA-ready, HIPAA-compliant environment. Do NOT expect a paying MCO in 30 days.
60-day build
Secure one design-partner MCO or a Medicaid-focused enrollment-broker/FQHC as a channel; run a live pilot on a member subset; measure retention lift vs. control.
90-day revenue plan
Convert the pilot into a paid per-retained-member contract — realistically 6-12+ months given MCO procurement, security review, and BAA/legal cycles. First revenue inside 180 days is optimistic, not likely.
Distribution path
Direct to MCO retention/quality/Stars teams, or white-label through an existing member-engagement vendor or Medicaid enrollment broker. All are relationship/procurement channels — the founder's stated weakness.
Pricing hypothesis
Per-retained-member success fee or PMPM SaaS; value story is 'each retained member = a full year of capitation.'
Technical difficulty
Moderate for the messaging agent; HIGH for the moat parts — HIPAA/PHI handling, 50 heterogeneous state submission portals, and per-state form logic. The eve SDK collapses channel plumbing but not the compliance or state-integration surface.
Legal / regulatory risk
HIGH: PHI/HIPAA, state Medicaid data-sharing rules, and eligibility-assistance regulations. Submitting eligibility filings on a member's behalf may implicate application-assister rules per state.
Platform dependency
Low on the government side (no deplatform risk), but real dependency on the eve/Chat SDK and on WhatsApp/Meta messaging policy for the outreach channel.
Founder fit
WEAK despite the surface 'forced-filer' shape. The founder's proven edge is a self-serve, per-upload portal tool sold to individual filers (FMCSA ELDT). Here the actual buyer is a regulated health-insurance enterprise requiring BAAs, security audits, and long procurement — exactly the enterprise-sales / long-trust-cycle / heavy-PHI profile he avoids. The 'forced buyer' (enrollee) and the 'payer' (MCO) are different parties, which breaks the pattern that makes his thesis work.
Breakout potential
High IF a single MCO contract lands, because it replicates across ~40 managed-care states and every plan feels the same capitation loss — but that upside is gated behind an enterprise sale he is poorly positioned to run solo.
Final recommendation
WATCH / PASS as scoped. The regulatory thesis is real and the market is large, but the buyer is enterprise health-plan procurement with heavy PHI/HIPAA burden and no observed buyer-side demand — a poor fit for a solo operator selling on demonstrated value. If pursued at all, do it as a white-label module to an existing engagement vendor, or pivot to the reachable version below.
Next action
Instead of building for MCOs, validate the reachable adjacent buyer: FQHCs, enrollment brokers, and Medicaid application-assister orgs who are grant/contract-funded to keep people enrolled and buy tools without enterprise procurement. Interview 5 of them about procedural-churn pain before writing code.