TL;DR: Vendor AI features are no longer something a church is choosing whether to adopt. They are switching on inside the church management system the church already pays for. We have watched the staff-trust failures cluster around the same five missing steps, so we wrote them out as a sequence any church can run, regardless of which ChMS sits underneath.
Core Insights:
The first real implementation data is in: Pushpay logged 15,185 AI search prompts across 331 accounts during beta, and the win was access, not novelty.
Only nine percent of churches have a formal AI policy, even though 93.5 percent of leaders are now engaging with AI in some form.
The right champion is not the senior pastor; it is the staff member who will use the tool most.
A thirty-day pilot with one feature, one team, and a written success metric prevents permanent “we are trying it” limbo.
Short, role-relevant training beats generic AI workshops. Sixty-one percent of leaders say they want tutorials for specific tools, not theory.
A church rolls out AI inside its existing ChMS in five stages, in this order: inventory what staff are already using, write a short shared policy, name a single champion who is not the senior pastor, pilot one feature with one team for thirty days against a written success metric, then expand with short role-relevant trainings. The sequence works because the technical setup is no longer the hard part. Pushpay’s AI People Search beta logged 15,185 prompts across 331 accounts with five times more staff using complex searches, and ACST’s Ministry Platform AI sets up in under thirty minutes. The trust work belongs to the church, not the vendor.
Table of Contents
Why Vendor AI Is Now an Implementation Question, Not an Adoption Question
Stage One: Take an Honest Inventory Before You Turn Anything On
Stage Two: Write the Thirty-Minute Policy Before the Pilot, Not After
Stage Three: Pick One Champion Who Is Not the Senior Pastor
Stage Four: Pilot One Feature With One Team for Thirty Days
Stage Five: Expand With Short Role-Relevant Trainings, Not Feature Walkthroughs
Frequently Asked Questions
Key Takeaways
Sources and References
Where We Go From Here
Why Vendor AI Is Now an Implementation Question, Not an Adoption Question
Through the first half of 2026, AI moved from a thing a church chooses to adopt into a thing that switches on inside the church management system the church already uses. The question on the table is no longer whether to bring AI in. It is how to roll it out without breaking trust with the staff who have to use it.
The vendor landscape made the shift hard to miss. Pushpay opened AI People Search to all ChMS customers in April 2026 after a beta that ran across 331 accounts. ACST announced Ministry Platform AI in May with a Pioneer Program for the first fifty churches. Ministry Brands shipped its Equip AI tool on June 10, 2026. We are tracking similar movement across Planning Center and Subsplash. For a fuller view, our pillar on what church management software vendors are actually doing with AI in 2026 maps the vendor-side picture in depth.
We will note up front that several of the numbers throughout this piece come from vendor-published research. Pushpay, ACST, and Ministry Brands have an interest in the story landing well. We cite them because the implementation detail they publish is the best available right now, and we read it accordingly.
The technical setup is no longer the hard part. ACST’s Ministry Platform AI configures in under thirty minutes through standard API credentials. Pushpay’s People Search activates with a switch inside the existing ChMS. The work that decides whether the rollout holds, or breaks, is the staff conversation around it. That work belongs to the church.
Key Point: The vendor handles the switch. The church handles the trust. AI rollout in a ChMS is now an implementation problem, not an adoption decision.
Stage One: Take an Honest Inventory Before You Turn Anything On
Before activating any vendor AI feature, find out what AI tools the staff are already using on their own. The inventory is the foundation; without it, a new vendor feature gets layered on top of an unmapped landscape, and the staff who have been quietly using ChatGPT for their newsletter draft go further underground.
The gap is real. Pushpay’s research with Barna found that around sixty percent of pastors use AI personally each month, while only five percent of churches have a formal policy in place. The same Barna and Pushpay collaboration reported that sixty-four percent of leaders say a policy is important, but only that same five percent actually have one. A majority of staff are using AI somewhere. Almost no one has mapped it.
The inventory conversation works best as a curious one, not an audit. The four questions we ask:
Which AI tools are you already using in your work, on any device?
What tasks are you using them for, week to week?
What information do those tools see when you use them?
What would make your current AI use easier or safer to do openly?
The point of the inventory is not enforcement. It is the input the next stage needs. The policy cannot account for what the team is doing if the team’s actual practice is invisible. As Pushpay frames it, the answers to those questions will often surprise leadership, and that surprise is the value of asking.
There is a sequencing reason to inventory before the vendor switch. Turning on Pushpay AI People Search or ACST Ministry Platform AI without knowing the existing AI footprint sets up the exact trust failure the rollout is supposed to prevent. The staff member who has been using a personal ChatGPT workflow now has to choose between continuing in the shadow or admitting it after the fact. Neither path builds trust.
Key Point: Inventory first. The staff are already using AI somewhere. A vendor feature switched on without that map will compete with whatever is already in motion.
Stage Two: Write the Thirty-Minute Policy Before the Pilot, Not After
The policy does not need to be a twelve-page document. It needs to exist. A thirty-minute staff conversation that produces a shared understanding of where AI is appropriate, where it is not, and who is responsible for what is enough to start. Light is acceptable; absent is not.
Pushpay’s writing on church AI policy makes the same point: a thirty-minute staff conversation that produces shared understanding counts as a policy. The bar is shared clarity, not legal documentation. ChurchTechToday’s 2026 State of AI in the Church report found that only nine percent of churches currently have a formal AI policy, while forty-seven percent of leaders say they want ethical guidance from a trusted source. The appetite is there. The document is not.
There are four decisions the thirty minutes needs to produce:
What data is allowed to touch which AI tools. Congregational records, giving data, pastoral conversations, and counseling notes sit at different sensitivity levels and need different rules.
What gets disclosed to the congregation. If AI helped draft a sermon outline, a newsletter, or a follow-up message, is that named?
Who has final sign-off on AI-generated communication before it goes out.
What gets retained, and what gets deleted, after an AI tool produces output.
Write the answers down, even informally. A shared doc that the team can point to is the asset.
Policy before pilot matters because retroactive rules feel like a takeaway, not a guardrail. Once a feature is live and a staff member is using it daily, a new rule introduced afterward reads as a correction of that person. Setting the rule before the switch reads as a shared standard. The difference is enormous in a small staff culture.
Vendor-side guarantees reduce technical risk but do not write the policy for the church. ACST’s role-based permissions, audit trails, and assurance that data is not used to train external models address the infrastructure layer. The policy layer, what the team decides to do with the tool, is still on the church to set. For a deeper walk-through, our piece on the AI policy questions every church staff needs to answer covers the full set we work through with ministries.
Key Point: A short, written, shared policy beats a comprehensive policy that never gets written. The policy is a precondition for the pilot, not its output.
Stage Three: Pick One Champion Who Is Not the Senior Pastor
The AI champion should be the staff member who will use the new feature most, not the senior pastor. For ChMS AI features like people search, giving lookups, or attendance trends, that means a connections director, a finance lead, a children’s pastor, or a small-groups coordinator. The senior pastor sponsors the rollout; someone closer to the work runs it.
Pushpay’s beta data on AI People Search shows the user pattern clearly. The six query categories that dominated the beta were driven by connections staff, children’s ministry leads, finance directors, small-groups coordinators, attendance trackers, and volunteer coordinators. Senior leadership rarely appeared in the heavy-use cohort. The features were built for the people doing the daily lookup work, and they used them.
The senior pastor is often the wrong champion because the senior pastor is often the lightest user. The champion needs daily use to surface real friction, because friction is what the pilot review needs to evaluate. A leader who tries the tool twice a month will not have the data to make the call at day thirty.
The champion’s job has three parts:
Be the first daily user of the new feature.
Collect what is working and what is not, in plain notes.
Run the thirty-day pilot review meeting.
The profile we look for: someone trusted by the team, technically curious enough to try things, honest enough to say when something does not work. Title does not matter. Trust does.
Ministry Brands’ conversation with Kira Brown on using AI in ministry without losing the human touch lands a related point: the people running the tool day to day are the ones who translate vendor framing into specific staff conversations. The champion is the translator.
Key Point: The champion is the heaviest user, not the most senior leader. Sponsorship and championship are different jobs.
Stage Four: Pilot One Feature With One Team for Thirty Days
A pilot has one feature, one team, a thirty-day window, and a success metric written down before it starts. The old workflow keeps running in parallel during the pilot. The success metric is the question the pilot answers, and it should be specific enough that a yes or no answer is possible at day thirty.
Pick the feature most aligned with current staff pain. From Pushpay’s six beta query categories, the highest-leverage starters are usually connections lookups or giving questions. The beta data showed time per complex filter dropping from minutes to about five seconds, with five times more unique users running complex searches than before. The story behind the numbers is access expansion: the staff who could not previously run a complex query suddenly could. That is the kind of outcome a pilot is built to confirm or rule out in a single church’s context. Before locking the pilot scope, the questions in our piece on what to ask your ChMS vendor about AI before you renew help clarify what the feature will and will not do.
One team only. Pulling three teams into a pilot at once dilutes the signal and triples the change-management load. The point of a pilot is a clean read on one variable.
Define the success metric in writing before turning the feature on. Examples that work:
Our connections director can produce next-step lists for new-attendee follow-up in under ten minutes.
Our finance lead can answer board questions about giving without exporting to a spreadsheet.
Our children’s ministry coordinator can pull current allergy and check-in notes for a Sunday in a single query.
Each of these has a yes or no answer at day thirty. “We are using the new feature” does not, because it measures activity, not value.
Parallel running is part of the design. Concordia Technology’s guidance on training staff through a system transition recommends running old and new workflows side by side, and staying available for ongoing questions for months rather than relying on a single training session. We apply the same principle to AI feature rollouts. The team needs the fallback, and the comparison itself is useful pilot data.
Where vendors offer structured pilot support, take it. ACST’s Pioneer Program for the first fifty churches on Ministry Platform AI offers vendor-supported onboarding for cohort-style pilots, which can shorten the time to a clean review. Whether or not the vendor offers a program, the church’s own thirty-day discipline is what produces the answer.
At day thirty, the champion answers the success metric, yes or no. The team votes on one of three outcomes: expand, extend the pilot by another thirty days with a refined metric, or stop. No fourth option. Drift into permanent trial is the failure mode this stage is designed to prevent.
Key Point: One feature, one team, thirty days, one written metric. The pilot’s job is to answer a specific question, not to demonstrate enthusiasm.
Stage Five: Expand With Short Role-Relevant Trainings, Not Feature Walkthroughs
Expansion happens only after the pilot review answers yes on its success metric. The training that follows is short, role-relevant, and focused on the three to five things each staff member will actually do with the tool. Generic feature walkthroughs do not stick; specific use cases do.
ChurchTechToday’s 2026 report found that sixty-one percent of church leaders want tutorials for specific tools and fifty-nine percent want ministry-specific use cases. They are not asking for AI theory. They are asking for the exact phrasing that gets the connections director the list of new attendees who missed last Sunday.
The training format we recommend: thirty minutes per role, focused on the three to five queries that staff member runs most often. The session is built around the actual tasks already on that person’s calendar. A children’s ministry coordinator’s session is different from a finance lead’s session, and that difference is the point.
Documentation matters as much as the live session. A one-page reference per role, in plain language, with the exact phrasings that worked during the pilot, gives the team something to return to. Without it, the training fades by the next staff meeting.
Ongoing support is the part most rollouts underestimate. Concordia Technology’s research on staff training through a software change makes clear that questions surface for months, not weeks, as staff hit tasks that only come up periodically. The annual stewardship campaign, the back-to-school children’s check-in surge, the year-end giving close, each one is a moment a new question shows up. Build the expectation that the champion stays available for those moments. The lessons here overlap meaningfully with what we wrote in what church management software migration actually involves, because the human side of a feature rollout and a full migration share the same gravity.
What expansion should not look like: a single all-staff lunch-and-learn where the AI feature is demoed once and never referenced again. That format checks a box and produces no behavior change.
The vendor ships the feature. The rollout sequence above is how a church actually lands it. The Friday pillar on the vendor-by-vendor AI rollout map covers the supply side; the five stages here are the demand side, the implementation work that turns a feature switch into a tool the team trusts.
Key Point: Short, role-relevant training sticks. Generic feature walkthroughs fade by the next staff meeting.
Frequently Asked Questions
How long should a church AI pilot run inside a ChMS?
Thirty days is the right default for a single feature with a single team. Shorter than that and the staff have not had time to hit the tasks that only show up every few weeks. Longer than that and the pilot drifts into permanent “we are trying it” status with no decision point. The thirty-day mark is the review meeting, not the end of use.
Who should own AI rollout in a church?
The senior pastor sponsors it. A staff champion who will use the tool most often runs it. For ChMS AI features, that usually means a connections director, a finance lead, a children’s pastor, or a small-groups coordinator. Sponsorship and championship are distinct jobs, and conflating them is one of the most common reasons a rollout stalls inside the first sixty days.
Do we need a formal AI policy before turning on vendor AI features?
Yes, in the lightest possible form. A thirty-minute staff conversation that produces a shared understanding of what data goes where, what gets disclosed, and who has final sign-off is a policy. We do not recommend waiting on a comprehensive document. We do recommend never running the pilot without something written down, because retroactive rules after a problem surface always feel like a takeaway.
What is the first ChMS AI feature most churches should pilot?
Whichever feature aligns with the staff role most starved for time on lookup work. For most churches that is people search or giving data lookups, both of which appear in Pushpay’s beta as the highest-frequency query categories. The pilot’s value is in collapsing a task that takes minutes into a task that takes seconds, with the same staff member doing it.
How do we measure whether the AI pilot worked?
Write the success metric down before the pilot starts. Pick a specific question that has a yes or no answer at day thirty. “Our connections director can produce next-step lists for new attendees in under ten minutes” is a good metric. “We are using the new feature” is not, because it measures activity, not value. The metric is the pilot’s reason to exist.
How do we keep AI rollout from feeling impersonal to staff and congregation?
The rollout sequence answers this by design. Inventory respects what staff are already doing. The policy is built with the team, not handed to them. The champion is one of them. The pilot is small and reversible. Trainings are short and role-specific. Each step keeps the human relationship in front of the technology, which is the point.
What about churches using a ChMS whose vendor has not shipped AI yet?
The same sequence still applies, with the inventory and policy stages doing the heaviest work. Most staff are using AI tools outside the ChMS regardless of vendor pace. Running the inventory and writing the short policy now means that when the vendor does ship, the rollout starts at stage three with the policy already in place and the staff conversation already had.
Key Takeaways
Vendor AI inside the ChMS is no longer an adoption question. It is an implementation question, and the implementation work belongs to the church.
The rollout sequence has five stages, in this order: inventory, policy, champion, pilot, expand. Skipping or reordering any of them is the most common cause of staff-trust failure.
A thirty-minute shared policy beats a comprehensive policy that never gets written. Light is acceptable; absent is not.
The AI champion is the heaviest user, not the most senior leader. Sponsorship and championship are different jobs.
A pilot has one feature, one team, thirty days, and a success metric written down before it starts. The old workflow runs in parallel until the review.
Training that sticks is short, role-relevant, and built around three to five real use cases. Generic AI workshops do not move the work.
Pushpay’s beta data shows the win is access expansion, not novelty. Five times more staff using complex searches means the right rollout removes barriers for people who would already do the work if they could.
Sources and References
Jonathan Louvis, “Find anyone in your church database fast”, Pushpay, April 8, 2026.
”The 2026 State Of AI In The Church: 93% Of Pastors Are In. Now What?”, ChurchTechToday, April 27, 2026.
”How Church Leaders Are Using AI (And What Concerns Them Most)”, Barna Group in partnership with Pushpay, March 26, 2026.
Hannah Hansen, “How to Train Staff on New Church Management Software”, Concordia Technology Solutions, November 25, 2025.
”Ep. 173 | Kira Brown: How to Use AI in Ministry Without Losing the Human Touch”, Ministry Brands Amplify, June 10, 2026.
Jonathan Louvis, “Most pastors use AI. Almost none have a plan for it”, Pushpay, March 16, 2026.
”ACST Launches Ministry Platform AI, Bringing Secure, Ministry-Aware AI to Churches”, Business Wire / ACST press release, May 7, 2026.
Where We Go From Here
Vendor AI inside the church management system is a real shift, and the implementation work is what decides whether it builds staff trust or quietly erodes it.
The next question most leaders run into is which feature to pilot first, and how to write the success metric in a way that gives the team a clean yes or no at day thirty.
If your ministry is working through how to roll out AI inside your existing ChMS, we would be glad to think it through with you. We offer no-pressure consultations where we listen first, then share what we have learned helping ministries navigate the same questions. Schedule a consultation.
