Supporter Inquiry Triage | Real Minds AI
Not-for-Profit /Decisioning live field guide · 8 min

Supporter Inquiry Triage

Reads each enquiry in a shared inbox, classifies intent and urgency, routes it to the right team, and drafts a values-aligned reply for staff to approve — so urgent requests surface first instead of waiting days behind routine ones.

theater/demos/nfp_supporter-inquiry-triage.html · sandbox · read-only
Open
FIG. 1

The live demo, running on fabricated data. Open it to step through the full flow — every output is shown for a person to approve before anything happens.

How it would work

Reads each supporter enquiry, classifies its intent and urgency, matches the supporter to your CRM, and drafts a values-aligned reply — then routes anything sensitive to a named person to approve before it sends.

Input 01
The shared supporter inbox

Every inbound message across channels — email, webform, phone notes — into one monitored inbox, plus the supporter record (giving history, supporter number) it can be matched against.

Agent 02
Classifies, routes, drafts

Reads each message, classifies intent and urgency, matches the sender to a CRM supporter number, and drafts a reply grounded in your own FAQs and approved policies — citing the text it used.

Output 03
A draft, with its working shown

A triaged queue with each message's category, urgency and a drafted reply. Routine replies are surfaced for a quick check; anything sensitive — hardship, complaints, gifts in wills — is routed to a named person to approve before it sends.

Where it works well

It reads every message the moment it lands and puts the urgent one at the top of the queue.

  • Done by hand, an enquiry waits until someone has time to read it — and the urgent one looks identical to the routine one until it's opened.
  • Best for a small team on a high-volume public inbox covering several audiences at once: donors, service users, media, volunteers.
  • At hundreds of enquiries a week, the recaptured hours go back into the supporter conversation, not into sorting the inbox.

The slow, invisible cost of a shared inbox is the triage itself — the next person to open it deciding by eye what each message is and what to do with it, while a crisis enquiry sits behind forty routine receipt requests.

Where it works badly

It is confidently wrong on the message that reads routine but isn't — and a clean draft hides the misread.

  • Weak on tone and subtext — sarcasm, distress under politeness, a complaint dressed as a question. It should flag for a person, not guess the feeling.
  • If most of your inbox is genuinely one-off, judgement-heavy correspondence, the classifier gives you less than your own reading already does.
The honest test

If you cannot say which categories in your inbox carry real consequence when misread — hardship, complaints, safeguarding, bequests — this tool will route them faster, not more safely.

A "please cancel my donation" that is really a grief or hardship message gets a tidy, correct-looking win-back reply. The draft looks finished; the misjudgement is invisible until a supporter is hurt by it. That is the trap.

What it doesn't do — and shouldn't

It drafts and routes. A person approves and sends. That boundary is deliberate.

WHAT IT DOES
Surfaces the intent and urgency it assigned, and why
Shows the FAQ or policy text the drafted reply is grounded in
Flags hardship, complaints and other sensitive cases to a named person
WHAT IT WON’T
Send any reply on its own say-so
Make a financial, booking or service decision
Decide whether a complaint is upheld or a hardship case is handled

A supporter inbox holds personal information about donors and beneficiaries, which an Australian charity handles under the Privacy Act and the Australian Privacy Principles. A wrong reply to a hardship, complaint or bequest enquiry is a trust and reputational risk a charity carries directly. The accountable person stays on the decision because the consequence lands on them — not the tool.

What your data has to look like

One inbox the tool can read, a supporter record to match against, and your own FAQs and reply policies in writing.

44%
Typical readiness
across orgs we see, before the first job
A single monitored inbox the tool can read
Usual weak point
Your FAQs and approved reply wording, written down
Needs shaping
A supporter record to match the sender against
Usual weak point
A written rule for what is "sensitive"
Needs shaping
Channel and basic contact details on each message
Usually ready
The real first job

The reply policies are usually the weak point — held in one person's head, or as a stale FAQ doc nobody maintains. Writing down what a good reply to each enquiry type actually says, and which categories must go to a human, is usually the real first job — larger and more valuable than the triage layer on top. Once that is clear, every routed message after it is faster and right by default.

Right fit if…
A small team monitors one high-volume public inbox covering several audiences
Most enquiries are routine and repetitive — receipts, address changes, event questions
You can write down your FAQs and what a good reply to each enquiry type says
You can name the categories that must always go to a person
Walk away if…
Most of your inbox is one-off, judgement-heavy correspondence
You have no supporter record to match a sender against
Your reply standards live only in one experienced person's head
You want a tool that answers supporters without anyone checking
Open questions

The worried-buyer questions, answered straight

It can draft a wrong reply — which is exactly why nothing sends on its say-so. It classifies intent and urgency, drafts from your own FAQs and policies, and shows the text it used. Categories you mark sensitive — hardship, complaints, safeguarding, bequests — route to a named person, not an automated reply. For an Australian charity, a mishandled supporter is a direct trust and reputational risk, so a person reads and approves those before anything leaves the inbox.
It works from a single monitored inbox and your written FAQs and reply policies. If your reply standards live only in one experienced person’s head and your channels aren’t consolidated, the drafts are only as good as what the tool can read. Getting your enquiry types, good-reply wording and sensitive-case rules written down is usually the first piece of work — and the piece that pays off across every message after it.
No. It removes the sorting — reading each message, deciding what it is and where it goes — so the coordinator spends their time on the judgement: the hardship call, the upset donor, the complaint that needs a real answer. The reply is still theirs to approve and send. The capacity it frees goes back into supporter-facing work, not into clearing the queue.
Current to your live policies and CRM. If the FAQ the draft quotes is last year’s version, or the supporter record is out of date, the reply is confidently wrong — a correct receipt amount for the wrong gift, a policy that has since changed. The honest test: do you know that the FAQs and supporter data it reads are the ones in force today?
A supporter’s contact details, giving history and the contents of their message are personal information that an Australian charity handles under the Privacy Act 1988 and the Australian Privacy Principles. Any deployment runs against your own inbox and CRM, not a shared pool — we scope where the data sits and who can see it as part of the build. The demo here runs entirely on fabricated data; David Okafor is not a real supporter.
No. It drafts to the policies it’s given and flags sensitive cases, but it does not certify anything. Your obligations to the ACNC under the Governance Standards, your DGR receipting, your privacy duties and any state-based fundraising rules stay with the accountable people in your organisation. The tool gets the routine reply most of the way; a person closes the consequential last step.
What it takes to build
3–4 weeks · 4 phases
Reused from template~70%
Bespoke to this skin~30%
stack · Claude · inbox + CRM integration · retrieval · review UI
What it would cost

Fixed scope, fixed price, fixed dates.

01
Bite-sized first piece
One contained change, low risk
02
Pilot build
Most builds land here
03
Embedded support
Scale on proof

Considering this for your org?

The honest place to start is a bite-sized first piece — one contained change, low risk. Tell us where your inbox hurts; we'll play it back, scope it, and show you what's possible.

More in Not-for-Profit
Case-Note Impact Synthesiser
View →
Inbox Triage
View →
Consultation Submission Drafter
View →
First-Gift Welcome Drafter
View →
How We Work Proof Talk to us
How We Work Proof Talk to us
Ask us anything