Doing more with less: where AI genuinely helps a small NFP team

In most of the not-for-profits we support, one or two people handle IT, comms and data, often on top of another job. When AI comes up in those organisations, the board has usually read something about it, and nobody has the time to try it. This post is part of our Practical AI for Not-for-Profits series. It covers where AI is worth a small team’s time and where we would hold back.

Our NFP clients include Guide Dogs NSW/ACT and several aged-care and community organisations. The examples below come from the administrative work teams like theirs carry every week: grant reporting, donor and volunteer records, policy documents and board papers.

Why a small team should make time for this

Geoffrey Huntley argued recently that teams too busy doing their job to experiment with AI are setting themselves up to be replaced. He writes about software engineers, and he is harsher than an NFP manager needs to be. His practical point still applies. If nobody gets a few hours a fortnight to try AI on low-risk work, the organisation never finds out what works for it.

Jenny Wanger’s write-up of a Denver product panel describes AI letting one person build alone, faster, taking on work that used to need several roles. That is a good fit for a two-person team. The same panel also described the downside. Work done alone builds up debt that someone else has to fix later, and people burn out trying to keep up with every new tool. Plan for both when you set this up.

Four kinds of work worth starting with

The safe starting points share two features. A person reads the output before it goes anywhere, and if the model gets something wrong, fixing it takes minutes.

Drafting

Grant acquittal narratives, donor thank-you letters, volunteer newsletters and first drafts of internal policies all suit a model. Give it two or three previously approved documents as examples, plus the program facts for this round, and have staff edit the result. Program numbers must come from your own records and never from the model, because a model will produce a plausible figure if you leave a gap.

Summarising

Funding guidelines, government consultation papers, board packs and meeting transcripts take hours to read and minutes to summarise. Ask for summaries with page or section references so the reader can check a claim against the source. For aged-care organisations, a short staff briefing on a regulatory update is a sensible administrative use. Summarising individual client notes belongs in the caution section below.

Data cleanup

Donor and volunteer databases collect duplicates, inconsistent addresses and free-text fields nobody can report on. A model is good at proposing a category for “how did you hear about us” answers, or flagging two records that look like the same person. Let the model propose changes in a separate column and keep the original values. A staff member approves a sample before any script writes to the CRM.

Monitoring

A scheduled job can check funder pages for new grant rounds, tag and route messages arriving in a shared inbox, or produce a weekly summary of helpdesk tickets. These run in the background and save a small amount of time every day. Because the output is a suggestion or a digest, a wrong tag costs very little.

Costing it before you start

API-based models charge per token, which is roughly a fragment of a word. Input and output have separate rates. Prices differ widely between a provider’s small and large models and change often, and most are quoted in US dollars. We have left current rates out of this post for that reason. Take them from the provider’s pricing page on the day you budget, and run the sum yourself:

# Monthly cost estimate for one AI task
docs_per_month = 200            # e.g. inbound grant reports or emails
input_tokens_per_doc = 4000     # about 3,000 words of source text
output_tokens_per_doc = 800     # about a one-page summary
input_usd_per_million = 0.0     # from the provider's pricing page
output_usd_per_million = 0.0    # from the provider's pricing page
aud_per_usd = 0.0               # today's exchange rate

monthly_usd = (docs_per_month * input_tokens_per_doc / 1_000_000 * input_usd_per_million
             + docs_per_month * output_tokens_per_doc / 1_000_000 * output_usd_per_million)
monthly_aud = monthly_usd * aud_per_usd

At NFP document volumes, the model bill is rarely the line to worry about. Staff time spent reviewing output and the cost of building and maintaining the integration are usually much larger, so budget for those properly. Two controls apply from day one. Set a hard monthly spend cap in the provider’s console, and choose the smallest model that handles the task well before you try a larger one.

Per-seat assistant subscriptions are a different purchase. They suit drafting and summarising done by individual staff, and the monthly cost is predictable. API access suits automated jobs such as data cleanup and monitoring, where no one is sitting at a chat window.

Where we hold back

Two areas need a different approach. The first is any decision that affects a beneficiary directly: eligibility, service prioritisation, waitlist order, or anything a person would reasonably want to appeal. The second is sensitive casework, such as client notes in aged care or family support and incident reports.

Much of this information is personal or health information under the Privacy Act. Organisations that provide health services are covered regardless of turnover, so many aged-care and disability providers fall under the Australian Privacy Principles even when they are small. Before any of this data goes to an external model, find out where it is processed and whether it is retained.

Oversight is the other problem. Developers have started building tools such as Airlock to sandbox AI agents and record what they do, because by default nobody can see it. Its makers note that by the fortieth approval prompt, people click yes without reading. Staff approving AI suggestions in a case system will slip into the same habit unless the design makes review a real step.

If AI touches casework at all, human sign-off is a requirement of the design:

• The model can draft a case note from a worker’s dictation. It cannot write to the client record.
• The worker reviews, edits and signs the note, and the record shows who approved it.
• No model output feeds care assessments, clinical judgements or eligibility decisions.
• Prompts and outputs are logged so you can audit them later.

A first project for a small team

This is the shape we suggest for a first build. It costs little to run and is easy to switch off:

• Input is a single document type arriving in a shared mailbox or SharePoint folder.
• A small scheduled function sends each item to a model API with a fixed prompt and a handful of approved examples.
• Output lands in a review queue, such as a SharePoint list, and never goes straight to donors or the CRM.
• A staff member approves, edits or rejects each item, and the decision is logged.
• The provider account has a spend cap, and personal information is either stripped first or kept out of scope.

Run it on one task for a month. Then count how many outputs staff accepted unchanged and roughly how much time they saved. That count tells you whether to extend the job to a second document type or stop.

PicNet builds production AI systems for Australian organisations, including not-for-profits working with tight budgets and small teams. If you have a task in mind, talk to us about what a first project could look like.