# Execution Scorecard: Benefit check bot

Score: 43/100

Tier: Research first

Benefit check bot scores 43/100 for execution readiness. The recommended next step is Recruit 5-10 benefits navigators at FQHCs or community nonprofits in two states to run the bot on 100+ real client intakes over 4-6 weeks. Measure whether it cuts average screening time versus their current process, the share of clients identified as likely eligible for at least one program they were not already enrolled in, and navigator-rated accuracy against a manual check. Target a willingness-to-pay signal: at least 3 orgs agreeing to a paid pilot.

## Bottlenecks
- Eligibility rules vary by state, county, and program and change frequently; maintaining accurate, to-the-dollar rules engines across jurisdictions is costly and a liability if estimates are wrong.
- The graveyard of well-funded predecessors (Benefits Data Trust's closure) shows the model is hard to fund sustainably and that buyers are often grant-dependent nonprofits with thin budgets.
- Handling SSNs, income, and immigration-status data triggers HIPAA/privacy obligations and demands strong trust, security, and consent design.
- Incumbents like findhelp, Benefit Kitchen, and free public tools (GetCalFresh, Benefits.gov BEST) already serve parts of this market and can add AI features.
- A broad AI assistant can flatten differentiation unless the wedge is painfully specific.
- The first release can become a generic dashboard if the job is not named tightly.
- Needs real buyer access, not only desk research.

## Accelerators
- Can talk to the buyer before writing much code.
- Can ship a narrow first-win demo quickly.
- Can use local-first research artifacts to keep validation moving without a large team.
- Use specificity as the wedge: one buyer, one workflow, one measurable result.
- Show proof earlier than broad competitors with before-and-after examples and small pilot data.
- Keep implementation lighter than incumbent suites or generic AI assistants.
- Concierge review or paid template

## Dated Launch Plan
- **2026-07-04 / Frame the wedge**: Write the one-sentence promise and test it in the strongest channel. Proof: Recruit 5-10 benefits navigators at FQHCs or community nonprofits in two states to run the bot on 100+ real client intakes over 4-6 weeks. Measure whether it cuts average screening time versus their current process, the share of clients identified as likely eligible for at least one program they were not already enrolled in, and navigator-rated accuracy against a manual check. Target a willingness-to-pay signal: at least 3 orgs agreeing to a paid pilot.
- **2026-07-07 / Interview 10 people who match the buyer persona.**: Create the lead magnet and use it to recruit interviews. Proof: Problem resonance: 5+ calls or 10+ detailed replies.
- **2026-07-11 / Ship a clickable demo or concierge workflow that produces the first useful artifact.**: Build the smallest demo that proves the first win. Proof: Activation: 25% of demo visitors complete the first-win path.
- **2026-07-18 / Run one paid pilot or collect explicit pricing objections before automating the rest.**: Delete any report section that feels generic before building. Proof: Commercial pull: 3 paid pilots, LOIs, or concrete procurement next steps.
- **2026-07-25 / Promote to a deeper build plan only after the wedge survives validation.**: Run the lead magnet and first-win demo tests. Proof: Fewer than five qualified buyers agree to discuss the workflow after targeted outreach.
- **2026-08-03 / Execution checkpoint 6**: Promote to deeper implementation only once the wedge survives interviews or paid-pilot outreach. Proof: Promote to a deeper build plan only after the wedge survives validation.

## Builder Prompt
Create a dated execution plan for "Benefit check bot". Keep the first milestone tied to Recruit 5-10 benefits navigators at FQHCs or community nonprofits in two states to run the bot on 100+ real client intakes over 4-6 weeks. Measure whether it cuts average screening time versus their current process, the share of clients identified as likely eligible for at least one program they were not already enrolled in, and navigator-rated accuracy against a manual check. Target a willingness-to-pay signal: at least 3 orgs agreeing to a paid pilot.. Use these bottlenecks: Eligibility rules vary by state, county, and program and change frequently; maintaining accurate, to-the-dollar rules engines across jurisdictions is costly and a liability if estimates are wrong.; The graveyard of well-funded predecessors (Benefits Data Trust's closure) shows the model is hard to fund sustainably and that buyers are often grant-dependent nonprofits with thin budgets.; Handling SSNs, income, and immigration-status data triggers HIPAA/privacy obligations and demands strong trust, security, and consent design.; Incumbents like findhelp, Benefit Kitchen, and free public tools (GetCalFresh, Benefits.gov BEST) already serve parts of this market and can add AI features.; A broad AI assistant can flatten differentiation unless the wedge is painfully specific.; The first release can become a generic dashboard if the job is not named tightly.; Needs real buyer access, not only desk research.. Use these accelerators: Can talk to the buyer before writing much code.; Can ship a narrow first-win demo quickly.; Can use local-first research artifacts to keep validation moving without a large team.; Use specificity as the wedge: one buyer, one workflow, one measurable result.; Show proof earlier than broad competitors with before-and-after examples and small pilot data.; Keep implementation lighter than incumbent suites or generic AI assistants.; Concierge review or paid template. Link the output to the Idea Builder prompt and do not expand beyond the first validated workflow.