Not-for-Profit /Customer-service agent interactive demo field guide · 8 min

First-Gift Welcome Drafter

Spots first-time donors who haven't been thanked, drafts a warm, personalised welcome sequence tied to the program they actually gave to, and queues it for staff to approve and send — targeting the sector's weakest metric, first-year donor retention.

Open the live demo

theater/demos/nfp_first-gift-welcome-drafter.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 a new gift, recognises it as a donor's first gift, drafts a warm welcome tied to the program they gave to, and queues every message for a fundraiser to approve before anything reaches the donor.

Input 01

The gift, as it lands

A new gift record from the CRM — the donor's name, the amount, the appeal or program they gave to — plus the receipt and any donor note attached.

Agent 02

Recognises, grounds, drafts

Checks the CRM for a prior match to confirm it's a first gift, reads the appeal and any tribute note, and drafts a short welcome sequence that names the program and the amount — citing the receipt and the welcome pack it drew from.

Output 03

A draft, in the review queue

A welcome sequence with every line and figure laid out for a fundraiser to read, edit and approve before it sends — and a held flag on anything sensitive, like a tribute gift, that needs a personal line first.

Where it works well

It catches the first gift while it's still warm — the window small teams keep missing.

Done by hand, a personalised welcome that names the right appeal is ten or fifteen minutes a donor — the first thing dropped in a busy campaign.
Best for a fundraiser or supporter-care lead drafting welcomes regularly: appeal spikes, new-donor onboarding, post-event giving.
At dozens of first gifts a week, the recaptured time goes back into the relationship — the phone call, the visit — not the keyboard.

The slow, invisible loss in fundraising is the new donor who gives once and never hears back in time — only about one in five first-time donors give a second gift, and the steward window closes in days, not weeks.

Where it works badly

It is confidently warm when the CRM is wrong — and a misjudged welcome stings more than a late one.

Weak where the donor record is incomplete — wrong name, wrong appeal, an undetected duplicate — because the draft reads as sincere either way.
It can't tell a genuine first gift from a re-lapsed donor the system never linked; it should flag the doubt, not paper over it.
On a sensitive gift — tribute, in-memoriam, a large unexpected one — the template is a starting point, never the sent message.

The honest test

If you can't trust that a "first gift" in your CRM is genuinely a first gift — and not a duplicate or an unlinked old supporter — this tool makes a warm mistake faster, not a warm welcome safer.

If the CRM has a duplicate the tool can't see, it welcomes a long-standing donor as brand new; if a gift is a memorial and the note isn't read, it drafts a cheerful thank-you into a moment of grief. That is the trap.

What it doesn't do — and shouldn't

It drafts. A fundraiser approves and sends. That boundary is deliberate.

WHAT IT DOES

Surfaces why it read the gift as a first gift, and the appeal it matched

Shows the figures it used — amount, deductible portion — and the source it cited

Flags a tribute or sensitive gift and holds it for a human line

WHAT IT WON’T

Send anything to the donor on its own

Create or merge a supporter record without a person confirming it

Decide that a delicate gift is fine to send a template against

A donor's name, gift and any memorial detail are personal information under the Privacy Act and the Australian Privacy Principles, and a charity carries conduct expectations under the ACNC Governance Standards. A clumsy or wrong welcome costs trust and a relationship — and the consequence lands on the organisation, not the tool. The accountable person stays on the send.

What your data has to look like

A clean first-gift signal in the CRM, and the gift tied to a real appeal.

Typical readiness

across orgs we see, before the first job

A reliable first-gift flag

Needs shaping

The gift linked to an appeal or program

Usual weak point

Donor name and contact as structured fields

Usual weak point

Tribute / in-memoriam captured at point of gift

Needs shaping

Receipt and deductible detail

Usually ready

The real first job

The first-gift flag is usually the weak point — donor records duplicated, old supporters never linked, so the CRM can't reliably say who is genuinely new. Fixing how donors are deduped and gifts tagged to appeals is usually the real first job — larger and more valuable than the drafting layer on top. Once the signal is clean, every welcome after that is warm and right by default.

Right fit if…

You take a steady stream of first gifts — appeal spikes, events, online giving

First-year donor retention is a metric you actually track

Your CRM reliably tags a gift to the appeal or program it funded

A fundraiser or supporter-care lead can approve each welcome before it sends

Walk away if…

Your donor records are duplicated and old supporters were never linked

Gifts arrive untagged, so you can't tell which appeal a donor backed

Most gifts are sensitive or bespoke — tributes, major one-offs — needing a human every time

You want welcomes to send automatically with no one reviewing them

Open questions

The worried-buyer questions, answered straight

It can draft the wrong tone — which is exactly why nothing sends on its own. When a gift is marked as a tribute or in-memoriam, the tool holds the draft and flags it for a fundraiser to add a personal line before anything goes out. It shows why it read the gift the way it did and which appeal it matched, and a person approves every send. The tool drafts; the fundraiser stands behind the words.

It is only as reliable as the first-gift signal in your CRM. If a long-standing supporter is split across duplicate records, the tool can read a repeat gift as a first one and welcome them as new — a warm but wrong message. Getting donors deduped, old supporters linked, and gifts tagged to the right appeal is usually the first piece of work, and the piece that pays off across every welcome after it.

No. It removes the blank-page drafting — naming the appeal, the amount, the tribute detail — so the fundraiser spends their time on the judgement and the relationship: whether the tone is right, whether this donor warrants a call rather than an email, what the next conversation should be. The welcome is still theirs to approve. The capacity it frees goes back into donor-facing work.

Current to the gift as it lands — the welcome window for a first gift is days, not weeks, which is the whole point of the tool. It works from the new gift record, the linked appeal and the donor’s current contact details. If the CRM is updated in a nightly batch or the appeal tagging lags, the tool drafts against stale context and the timing advantage is lost.

A donor’s name, gift, contact details and any memorial note are personal information under the Privacy Act and the Australian Privacy Principles. Any deployment runs against your own systems and data handling, 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; Margaret Hollis is not a real donor.

It drafts a confirmation that the receipt is on its way and can state the deductible amount, but it does not issue the receipt or certify its wording. Gifts of $2 or more to a DGR-endorsed charity are tax-deductible, and a receipt has to carry the required detail — your organisation’s name, ABN, and that it is for a gift — under ATO rules. A person confirms the receipt and its wording are correct before the welcome goes out.

What it takes to build

3–4 weeks · 4 phases

Reused from template~70%

Bespoke to this skin~30%

stack · Claude · CRM API · template engine · review queue

What it would cost

Fixed scope, fixed price, fixed dates.

Bite-sized first piece

One contained change, low risk

Pilot build

Most builds land here

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 it hurts; we'll play it back, scope it, and show you what's possible.

Book a call How we work