Update the church website by sending an email.
A website platform for churches of any size, with two ways to edit: a simple dashboard for staff, and an email address for everyone else. Write the update the way you would tell a friend. Confirm the preview. It’s live.
Please add our Fall Festival, Saturday Nov 14, 12 to 4 in the fellowship hall. Free food and games. Flyer attached.
Fall Festival
Sat · 12–4 PM · Fellowship Hall
A church’s website is often the first place a visitor walks in, and the most out-of-date room in the building. EZEdit Mission makes keeping it current as easy as sending a message.
Designing church websites taught me that a simpler dashboard helps, but some people will never log into anything. This concept meets each church where it already works: in a dashboard for the staff who want one, and in their email inbox for the pastor who doesn’t.
Church sites go stale because updating them needs a login, a password and confidence most volunteers don’t have.
One content system with two front doors: a trimmed dashboard and an email address that AI reads and turns into a previewed change.
Nothing goes live from an email until a person confirms the preview. The AI interprets; people decide.
The tool is not the bottleneck. The login is.
On church sites I’ve built, I cut the editing dashboard down to a handful of things staff actually change. Even so, every change still depended on someone remembering a URL, a username and a password, then finding the right screen.
Meanwhile, the real updates were already being written somewhere else: in emails, group texts and bulletin drafts. The information existed. It just never reached the website.
Pastors are the clearest case. They are often the source of the update and the least likely to log in. The person who does log in is often a volunteer who heard about the change secondhand.
How might we let a church update its website from the tools it already uses, without losing accuracy or control?
These observations come from designing church websites and from working inside church ministry. They are assumptions to test with more churches, and the validation plan below is designed to check them.
Different sizes, different editors
Attendance shapes who edits the site and how much control leadership needs. These segments are working assumptions to validate.
Small church
Under 100 peopleThe pastor and a few volunteers do everything. No paid staff for communications.
- Updates come from the pastor directly
- One or two people allowed to change the site
- Weekly changes: banner, events, sermon link
Mid-size church
100 to 500 peopleA part-time office administrator, plus ministry leaders who each own a corner of the calendar.
- Admin runs the dashboard
- Ministry leaders email updates for their own ministry
- Admin approves changes from leaders
Large or multi-site
500+ people, one or more campusesA communications team guards the brand. Campus pastors and ministries send requests all week.
- Email becomes a request queue, not direct publishing
- Changes are tagged to a campus
- Two-step approval and a full audit log
Two front doors, one source of truth
Both paths write to the same content, follow the same permissions, and show up in the same activity log. A change made by email can be fixed in the dashboard, and the reverse.
For people who like to see the controls
The site’s own /admin, branded to each church, showing only what churches actually edit.
- Service times, events, sermons, leaders, photos by spot, banner
- Shared form inbox with privacy by role
- Best for office admins and comms teams
- Full control: edit, schedule, undo
Same roles
One log
For people who will never log in
Each church gets a private address. Approved senders write in plain words and attach photos or flyers.
- No app, no password, works from any phone
- AI turns the message into a proposed change
- A preview email comes back to confirm
- Best for pastors and ministry leaders
From inbox to live page
This is technically realistic today. Email services such as Postmark, Mailgun and SendGrid can receive messages for an address and pass each one to an app. From there, a language model reads the message, matches it to the church’s content, and drafts a change.
- Send
An approved person emails updates@ their church’s address.
Person - Verify sender
Checks the approved list and email authentication, so a spoofed address fails.
System - Understand
AI identifies the type of change and pulls out dates, times, places and names.
AI - Check
Compares with the live site: conflicts, past dates, missing details.
AI + rules - Preview
A reply shows exactly how the change will look, with anything uncertain called out.
Person - Confirm
Tap Publish or reply YES. Larger churches route to an approver instead.
Person - Live + receipt
The page updates. A receipt email includes the link and a one-tap undo.
System
Try four real-world emails
Each sample shows the incoming message, what the system understood, and the preview it sends back. Church and names are fictional.
The AI reads. People publish.
Email is easy to send and easy to fake, and church websites speak for the pastor. These guardrails make the convenient path a safe one.
Each church keeps a short list of who may send updates. Messages must also pass email authentication checks, which blocks most spoofing.
By default, every email change needs a confirmation. The preview shows the change exactly as visitors will see it.
Publish links expire and only work for the person who sent the update. Forwarding the preview doesn’t pass on the power to publish.
Email can’t delete pages, manage people, or change settings. Those stay in the dashboard behind a login.
Prayer requests and form entries can’t be requested or returned by email. The AI never sees them.
Each receipt has a one-tap undo. The activity log records who changed what, from which path.
Approval rules by church size
| Setting | Small | Mid-size | Large / multi-site |
|---|---|---|---|
| Who can email updates | Pastor plus 1–2 people | Staff and ministry leaders | Anyone on staff, as requests |
| Who confirms | The sender | Sender for their ministry; admin for site-wide items | Comms team approves everything |
| Scope per sender | Whole site | Limited to their ministry pages and events | Limited by ministry and campus |
| Banner and urgent closings | Sender confirms | Admin or pastor confirms | Campus pastor or comms confirms |
| Sermon summaries | Pastor approves | Pastor approves | Teaching pastor approves |
| Dashboard | Optional | Primary for admin | Primary, with review queue |
Recent changes
Real emails are messy
People write updates on the go, in shorthand, inside long reply chains. The design has to expect that.
| Situation | What the system does | Why |
|---|---|---|
| “This Sunday” sent late Saturday night | Resolves to an exact date and shows it in bold in the preview: “Sunday, Nov 8” | Relative dates are the most common source of error |
| Several updates in one email | Splits them into separate changes, each confirmed on its own | One bad item shouldn’t block or sneak in with the rest |
| Only a flyer image, no text | Reads the flyer and lists what it found; flags any text it couldn’t read clearly | Many churches already make flyers first |
| Long reply chain with signatures | Uses only the newest message and ignores quoted text and signatures | Old details in a thread can contradict the new ones |
| Conflicts with an existing event | Asks: “Replace the Nov 14 Bake Sale, or add both?” | Updates often mean “change,” not “add” |
| Date already passed | Holds the change and asks if the year or date is wrong | Catches typos before visitors see them |
| Campus not named (multi-site) | Uses the sender’s home campus, then asks if it applies to all campuses | Prevents one campus’s change from showing everywhere |
| Message in Spanish or Korean | Understands it and offers to publish in that language, English, or both | Many congregations worship in more than one language |
| Grief or funeral announcement | Uses a gentle, plain template and never adds celebratory wording | Tone mistakes hurt families |
| Request outside email’s scope (“delete the youth page”) | Explains it can’t do that by email and links to the dashboard | Destructive actions need a login |
Failure states
One clear question by reply is faster than a wrong guess going live.
Silence never counts as approval. One reminder, then the change quietly expires.
Say what happened, confirm nothing broke, and give a manual way forward.
Fixing a mistake should be as easy as making the update was.
Why it works this way
Email first, not a new app
Everyone on a church staff already has email on their phone. A new app means downloads, passwords and updates, and most pastors would never open it.
Trade-off: email is easier to spoof than an app login, which is why sender checks and confirmation links are required.
Confirmation on by default
The AI’s job is to save typing, not to make decisions. A preview step catches the errors language models are known for, like wrong dates and invented details.
Trade-off: one extra tap per update. If testing shows confirmation fatigue, an admin could let trusted senders skip previews for low-risk items like the banner.
Same permissions in both paths
A youth leader who can only edit youth events in the dashboard can only update youth events by email. Rules never depend on which door you use.
Trade-off: the AI must know each sender’s scope and say plainly when a request is outside it.
Scale by settings, not separate products
Small, mid-size and large churches use one platform with different approval rules. A church that grows changes settings instead of moving to new software.
Trade-off: settings must stay simple for small churches, so defaults are set by size during setup.
Test the behavior before building the AI
The riskiest assumption is that pastors and leaders will actually send updates by email and confirm previews. That can be tested by hand before writing any AI code.
Interviews
Talk with 8–10 pastors and church admins across all three sizes about how updates move today and where they stall.
Concierge pilot
Give 2–3 churches an update address for four weeks. I read each email and send previews by hand, then publish on confirm.
Assisted pilot
Add AI drafting behind the scenes, with me reviewing every preview before it goes out. Compare errors with the manual phase.
Self-serve beta
Turn on automatic previews for pilot churches, with confirmation always required and weekly review of the activity log.
What I would measure
Share of churches whose site changed in the last 14 days, before and after.
Minutes from sending an email to the change appearing on the site.
Previews confirmed without corrections. Low numbers mean the AI is misreading people.
Published changes later undone. The goal is near zero.
Open questions
- Will people trust a link in an email to publish?Some may worry it’s a scam. The pilot will test wording and whether replying YES feels safer than a button.
- Is confirmation fatigue real for weekly senders?If so, trusted-sender rules for low-risk changes are the next design problem.
- What does each email cost to process?AI and email-service costs need to fit a small church’s budget.
- Should text messages be a third path?Many leaders text more than they email. Texting adds carrier registration and cost, so it waits until email proves the behavior.
Design for the person who won’t log in
A simpler dashboard solves for the staff member willing to open a tool. This concept starts from the opposite person: the pastor who has the update in their head and no patience for software.
Designing for AI here was less about clever generation and more about the edges: when the system should ask instead of guess, what it must never touch, and how to make undoing a mistake as easy as making it. The interface is mostly email. The design is mostly trust.