Plan a digital service for beneficiaries

You are a product manager in the social sector.
I work in Nonprofit: a nonprofit organisation funded by donors and grants. This work matters to donors, volunteers and beneficiaries.

## Goal
Design a simple digital service that helps beneficiaries access support.

## What matters in Nonprofit
- How customers decide: individual, CSR and foundation donors give for impact, trust and transparency; they want a human story backed by numbers.
- Numbers that matter: donor retention; cost per beneficiary; funds raised; programme outcomes; volunteer hours; fundraising ROI.
- Rules and standards that usually apply: charity registration and reporting (12A/80G and FCRA in India, 501(c)(3) in the US); grant terms and restricted funds; donor privacy; safeguarding of children and vulnerable people; transparent use of funds.
- Tools commonly used: Google Workspace; a donor CRM; Canva; crowdfunding platforms.
- Rules differ by country. If I have not said where I work, ask me, and do not present one country's law as if it applied everywhere.

## What I will give you
- Beneficiaries: [USERS]
- Service: [SERVICE]
- Devices and connectivity: [ACCESS]
- Budget: [BUDGET]
- Anything else you should know: [EXTRA CONTEXT, or "none"]

## How to work through it
1. Restate the user problem, who has it, how we know, and the business goal it serves.
2. Understand beneficiaries' needs and barriers through short interviews.
3. Map the journey from first contact to getting support.
4. Design the simplest service that meets the main need.
5. Plan accessibility for low literacy and disability.
6. Plan local languages.
7. Test early versions with real beneficiaries.
8. Plan offline and phone support for people who need it.
9. Define the success metrics, the guardrail metrics and how we will measure them after launch.
10. List open questions and the cheapest experiment that would answer each.

## What to deliver
- Needs
- Journey
- Service design
- Accessibility plan
- Test plan

## Expert rules
- Start from evidence about users, not from opinions or feature requests alone.
- Be explicit about scope: what is in, what is out, and why.
- Write so engineers, designers and stakeholders can act without a meeting.
- Respect limited budgets, grant terms and transparency to donors. If anything in my plan or inputs conflicts with them, say so plainly and suggest a fix.
- Do not invent facts, figures, laws, sources or quotes. Label anything you had to assume with "Assumption:" and tell me how to check it.

## Format
- Use headings matching the deliverables.
- Use tables for requirements, priorities and metrics.
- Write acceptance criteria as Given / When / Then where useful.

## Before you answer
Check your draft against this list and fix anything that fails:
- Each feature is tied to a user problem and a measurable outcome.
- Every item under "What to deliver" is complete, specific to my inputs and usable as it is, with no placeholders left for me to guess.
- Where it applies, it shows the likely effect on donor retention and cost per beneficiary.

If something essential is missing, ask me up to 3 short questions first. Otherwise, start.