Case management requirements checklist: a worked example with our builder
A useful case management requirements checklist starts from your sector, your services and your field conditions, not from a vendor’s feature list. Answer seven questions, and you get a prioritised list of must-haves, a sketch of the records you’ll need and a signal for whether to buy, configure or build. Below we run one organisation through that process. For vendor comparisons and pricing, see our case management software for nonprofits guide.
The organisation
An illustrative example, based on the kind of organisation we often work with: a child-rights nonprofit in India. Its caseworkers do home visits in districts with patchy signal, run counselling, refer children to health and education partners, and support school re-enrolment. About 40 staff will use the system. Partner agencies need to update referrals. It serves children under 18. It is not part of a humanitarian coordination group.
Step 1: the seven inputs
| Question | Answer |
|---|---|
| Sector | Child protection |
| Services | Home visits, counselling, referrals to partner agencies, education / tutoring support |
| Where you work | India |
| Field conditions | Mostly field with patchy connectivity |
| Team size | 11–50 |
| Partners see or update records? | Yes |
| Serves children under 18? | Yes |
Step 2: what lands in the checklist
Base must-haves (every organisation). Person record with unique ID; intake with duplicate check; consent with version and date; assessment form; case plan with goals, actions, owners and due dates; categorised case notes; follow-up reminders; closure with reason and approver; role-based access; audit trail; outcome fields; supervisor caseload dashboard.
Child protection module (must). Safety plan; separate allegation and finding records; best-interest review step as a human gate; restricted narrative notes; partner referral confirmation.
From the services (should, unless promoted). Visit planner with GPS check-in (home visits); appointment scheduling and session notes (counselling); attendance and progress (education support). Referrals to partners promote the referral status loop (sent, accepted, received, closed) to a must.
From the flags (must). Mostly field adds offline mobile forms, a sync-before-sign-out warning, a post-sync duplicate review queue and remote device wipe. Partners add a partner role limited to received referrals and export logging. Children add guardian consent and child assent fields.
Compliance note. India plus children shows: “DPDP Act 2023 + Rules 2025: notice, consent, breach reporting within 72 hours to the Board, retention rules. Verifiable parental consent from May 2027.” Our guide to DPDP consent notices for NGOs has sample wording for the notice itself.
That is roughly 27 must-haves and 3 should-haves, which sounds like a lot until you notice most are rules about who sees what, not extra screens.
Step 3: the buy, configure or build signal
The builder scores towards “build” using six simple rules:
| Rule | Points | This organisation |
|---|---|---|
| Sector is "Other / multi-programme" | +2 | 0 |
| 3 or more services selected | +2 | +2 |
| India or "Other" region selected | +1 | +1 |
| Team size 51+ | +1 | 0 |
| Partners see or update records | +1 | +1 |
| Mostly field | +1 | +1 |
| Total | 5 |
A score of 3–5 reads “Configure a platform (Salesforce, Zoho Creator) around your workflow.” Had the organisation answered yes to the humanitarian coordination question, the builder would override the score and say “Look at Primero first.” A US homelessness programme would get “Use your CoC HMIS (or an HMIS-compatible product)” whatever its score.
The signal isn’t a verdict. It tells you which shortlist to build. For a score of 5, we’d test one configurable platform and one specialist product with three real cases each.
Step 4: the data model sketch
The builder draws the records triggered by the answers: Person, Household, Case, Assessment, Case plan, Action, Referral, Partner, Service, Note, Consent, Closure, plus Safety plan, Allegation and Finding for child protection. The relationships are the part worth showing a vendor: one person has many cases; a case has many assessments, one case plan and many referrals; a case plan has many actions; many referrals go to one partner; one person has many consent records. If a vendor’s product can’t represent “one person, many consent records”, you’ve learned something important in five minutes.
Step 5: turn it into a requirements document
Copy the checklist into a one-page document with four headings: must-haves, should-haves, access rules (attach your permission matrix from our role-based access deep dive), and compliance notes. Send the same page to every vendor and ask them to mark each line “standard”, “configured” or “custom”. It makes demos comparable.
If you also run a wider programme registry, check how these records connect to it in our beneficiary management system guide.
Build spec for the dev team
Find your gaps first
The builder tells you what your case system needs. EdZola’s free nonprofit technology assessment tells you where your organisation stands today across six areas, in about ten minutes, with the two areas to fix first. Your answers stay in your browser.
Take the free technology assessment →