Most churches have a box at the back. Connect cards, prayer requests, a slot for "please call me". People fill in a card on the way out and drop it in. It works because someone empties the box. Someone carries the cards to a desk, reads each one, and makes sure the right person picks up the phone. The box does none of that. The box just holds the cards until a human gets to them.
Now let the cards arrive all week, not only on a Sunday, and from people watching the service from another town. The emptying stops being a five-minute job after the last hymn. Cards pile up. Two arrive from the same person and nobody notices. One asks for a call that never comes, not because anyone was careless, but because the box outgrew the person emptying it.
That box was a church's website.
What the church asked for
We build for a church that gathers people through its website as well as its doors. The site carries a few plain forms: a prayer request, a place to record a decision someone made during a service, a "stay connected" card for anyone who wants to hear more. Each one is a card dropped in the box.
The brief was the emptying. The forms were filling faster than anyone could keep up with by hand, and submissions were landing in one place while the people who do the follow-up worked in another. Could we get every card, from every form, into the one list the team actually works from, quickly and without the same person turning up twice?
What we built
A small, boring machine that empties the box. Every few minutes it checks the forms, takes anything new, and drops it into the contact system the team already opens every day. No new screen to learn, no second place to check.
Two things mattered more than speed. The first: it never files the same card twice. If the machine runs again before a submission has been dealt with, or if someone taps "send" twice on a patchy signal, the person still shows up once, not three times. It matches on something unique to each submission and updates the existing record instead of adding another. Run it a hundred times and you still get one card.
The second: everything new lands marked New, and stops there. The machine's whole job is to carry the card to the desk. It does not decide what the card means.
The line we didn't cross
We could have gone further. We could have had the machine read each submission, match it to an existing person, file it under their name, and mark it handled. No human in the loop at all. It would have demonstrated beautifully in a boardroom.
We deliberately didn't, in two places.
A prayer request can be anonymous. Someone may write one without leaving a name, and that choice deserves to be honoured, not quietly undone by a system that files everything under somebody. So the machine never forces an anonymous card onto a named record. If it cannot tell who someone is, it does not guess.
And the follow-up itself stays with a human: deciding that this decision needs a call this week, that this request should go to a particular person, that this one is delicate. A person reads each new card and routes it. The machine gets the cards to the desk faster and cleaner than a volunteer ever could on a Sunday morning. It stops at the desk. The caring starts there.
Automate the emptying of the box. Never automate the reading of the cards. The machine is good at carrying; it is not good at caring, and it should not be asked to pretend.
What travels out of this
None of this is specific to a church.
Automate the plumbing, not the judgement. Collecting, de-duplicating and routing a pile of incoming things into one place is honest work for a machine. It's tedious and it's rule-shaped. Deciding what each one means, and who it belongs to, usually isn't. The win is that the automation hands a person a clean desk, not that it clears the desk on their behalf.
Idempotency isn't a technicality — it's whether the same person gets phoned twice. A collector you can run again without making a mess is the difference between a clean list and someone receiving three identical calls. "It ran twice" should be a non-event, and it only is if you build for it from the start.
What you refuse to automate is a design decision too. The most considered part of this build is the part we left to a person, on purpose. Anonymous stays anonymous; the follow-up stays human. Writing down where the machine stops is as much of the work as writing down what it does.
The honest opinion underneath it: a good deal of what gets sold as "the AI runs the whole workflow" is really automating the one step that should have stayed human. That step just happens to be the impressive one to demo. The unglamorous truth is that the machine earns its place by doing the carrying, reliably and without complaint, so the people are freed for the part only people can do. Build the machine that empties the box. Then leave the cards to someone who can read them.
For the technical reader
The forms live on the church's site and write each submission to a hosted Postgres database (Supabase), one table per kind of card. The "machine" is a scheduled automation (built in n8n) that runs every few minutes. It reads the new rows over a read-only database role (the collector can see submissions but cannot alter the source of truth) and upserts them into the ministry's off-the-shelf CRM, the tool the team already lives in.
The dedupe is an idempotent upsert keyed on a value unique to each submission. Re-running the job, or a double-submit from a flaky connection, updates the existing record rather than inserting a second one. The job is safe to run as often as you like, which is exactly what lets it run unattended. An unattended job that isn't safe to repeat is just a duplicate generator with a schedule.
Every upserted record carries a triage status that starts at New. The automation only ever creates or updates the raw submission and sets that status; it never links a submission to a master contact and never marks anything handled. That linking-and-routing step is a person working a filtered "New" view in the CRM. Two deliberate restraints sit in that gap: an anonymous submission (a prayer request left without a name) is never auto-attached to a named contact, and no follow-up is ever considered done by the machine. The scheduler carries. The person decides.