The question this answers
Who exactly can apply, and how do we explain it so everyone understands?
What the problem looks like without clear eligibility rules
Your guidelines say applicants must be “not-for-profit organisations operating in the community sector.” Sounds clear enough.
Then the enquiries start. Does a social enterprise count? What about a charity that’s registered interstate but operates locally? What about an auspiced group without its own ABN? What about a local council?
On a small grant program, staff can handle these questions one by one. At volume, it breaks. Every ambiguous rule becomes a queue. Every edge case becomes a judgement call. Different staff give different answers. Applicants who should apply don’t. Applicants who shouldn’t apply do. Your enquiries line is clogged with questions your guidelines should have answered.
The problem isn’t that eligibility wasn’t defined. It’s that it was defined in language that created more questions than it answered.
What I deliver
A publication-ready eligibility schedule that sets out:
- Who is eligible (with specific categories, not general descriptions)
- Who is not eligible (explicitly stated, not implied)
- How commonly disputed scenarios are treated (the grey areas, resolved in advance)
- Any conditions or exceptions (and how they’re verified)
It’s written in plain language, formatted for direct inclusion in your guidelines. Not a policy paper. Not a legal memo. A practical tool that lets applicants self-assess without calling your team.
The goal is eligibility rules so clear that applicants know immediately whether to proceed, and staff don’t have to interpret the same edge cases over and over.
What good looks like vs what bad looks like
Bad: “Eligible applicants include incorporated not-for-profit organisations with a demonstrated capacity to deliver projects aligned with program objectives.”
This sounds precise but resolves nothing. What counts as “demonstrated capacity”? Is a registered charity automatically not-for-profit? What about unincorporated groups? Every vague phrase generates enquiries.
Good:
| Policy intent | Translated to | Verification | Why it’s hard to game |
|---|---|---|---|
| “Support regional agricultural businesses” | Do you grow, process, or wholesale agricultural products? (select from list) | BAS statements showing agricultural income; ABN industry code as secondary check | Income source verified through ATO, not just a claim |
| “Established businesses” | Have you been trading for at least 2 years? | 8 consecutive BAS statements | Consistent ATO-lodged history, can’t be manufactured yesterday |
| “Genuine operators, not shell entities” | Do you have employees or regular trading activity? | STP payroll summary + bank statements showing regular transactions | Cross-referenced, ATO-reported, pattern over time |
| “Businesses experiencing hardship” | Has your revenue declined by more than 20% in the past 12 months? | BAS comparison: current year vs prior year; bank statements to confirm | Two sources must align, both show history |
| “Local businesses” | Is your primary place of business within [region]? | Utility bills + ABN address + bank statement address must all match region | Multiple documents, multiple sources, must align |
An applicant can look at this and know: do I actually have this evidence? Can I show consistent history across multiple sources? If yes, proceed. If no, this program isn’t for me.
The principle: triangulate. No single document trusted alone. History beats registration. ATO-reported beats self-declared.
Why it matters
Eligibility is the first gate. If it’s fuzzy, everything downstream gets harder: more enquiries, more ineligible applications, more inconsistent decisions, more complaints.
On a small program, you can absorb ambiguity. At scale, ambiguity is a bottleneck. Every unclear rule costs staff time. Every disputed edge case becomes a queue.
Clear eligibility rules resolve the hard calls before applications arrive. Applicants self-assess. Staff aren’t interpreting the same questions repeatedly. The program scales without needing more eyeballs on routine eligibility decisions.
Other Eligibility Design Deliverables
“Why can’t your staff agree on who’s eligible?” → Eligibility architecture designed so routine decisions are determined by structure, not interpretation. Ambiguity is resolved at the design stage. Staff apply rules rather than exercise judgement. When eligibility outcomes are consistent regardless of who applies them, the design is working.
“Why Are Ineligible Applicants Still Getting Through?” → Front-end eligibility logic built into the application pathway so ineligible applicants are filtered before they invest time and before staff need to intervene. The program enforces its own rules rather than relying on staff to catch what the design should have prevented.
