The children’s director sat at the folding table in the supply closet, the one with the wobbly leg and the permanent marker stain shaped like Texas. Her laptop fan whined as the planning tool loaded its afternoon suggestions. Three craft options appeared in the side pane, each one bright with stock photos of construction paper and glue sticks. She scanned the list, then reached for the small trust toggle at the top of the pane and switched it off. The recommendations disappeared. She exhaled, opened the blank lesson template, and started typing from memory instead.
She had tried the suggestions twice already that month. Both times the activities called for items the budget line did not cover, and both times she had spent an extra evening driving to two different stores looking for substitutes. Flipping the trust toggle was faster than arguing with the interface.
Solomon’s judgment offers a useful lens here. Two women claimed the same child. The king did not search for more data or run another test. He watched which person was willing to lose the outcome rather than harm the person in front of them. The real parent revealed herself by her readiness to override the proposed solution. Modern planning tools rarely test for that same willingness. They optimize for suggestion volume and measure acceptance rates, then wonder why the people closest to the work keep turning the suggestions off.
This matters because the person sitting at the volunteer desk already carries the constraint the model cannot see. She knows the supply closet inventory, the parent who always forgets to send scissors, and the fact that the church van is in the shop this week. When the interface treats her override as a failure state instead of the normal next step, it adds friction exactly where the work is most fragile.
Why the Trust Toggle Appears at the Point of Use
Most AI planning features ship with suggestions turned on by default, a choice usability research shows users rarely revisit. The assumption is that more options will help the time-pressed user. In practice the suggestions arrive already filtered through averaged data from thousands of other churches. What remains is often a list of activities that require either money or prep time the current volunteer does not have.
I watched the same pattern repeat across three different children’s ministry tools last year. Each time a new recommendation engine rolled out, the first week showed high click-through numbers. By week three the internal dashboard showed a spike in users who had disabled the pane entirely. The product team read the drop as disengagement. The volunteers described reaching for the trust toggle as finally being able to finish the task.
The break happens because the default carries an implicit claim: the model knows the local constraints better than the person who just counted the glue sticks. When that claim proves false, the user does not refine the suggestion. She removes the entire channel. Solomon would recognize the move. The one who truly bears the outcome will cut off the process rather than accept a solution that harms what she is responsible for.
The Override Cost No Dashboard Shows
Every extra click required to turn suggestions off carries a hidden cost. The volunteer has already opened the tool, seen the list, evaluated each item against her actual supplies, and then hunted for the setting. That sequence takes thirty to forty seconds on a good day. Across a quarter it adds up to hours that never appear in any usage metric because the time is spent outside the product.
The deeper cost is eroded trust. After the third time a suggestion set proves unusable, the volunteer stops believing future suggestions will be relevant. She treats the pane as noise rather than help. Product teams often respond by adding more personalization signals, yet the signals they request (budget ranges, supply lists, volunteer skill tags) are exactly the data points the volunteer does not have time to maintain inside the tool.
Solomon’s test still applies. The person willing to discard the proposed plan is usually the one who understands the real stakes. Forcing her to keep justifying the discard only increases the distance between the model and the work.
Designing the Trust Toggle Before the Feature Ships
The practical fix begins with treating the trust toggle as a core control rather than a settings afterthought. Place it directly beside the suggestion pane, not buried three menus deep. Label it plainly: “Hide suggestions for this plan.” Make the choice sticky for that user and that planning cycle so she does not repeat the action every time she opens the lesson.
Teams that have done this report an unexpected result. When the off-switch is cheap, more volunteers experiment with suggestions in the first place. They know they can dismiss the output without penalty, so they glance at it instead of preemptively disabling the whole feature. The acceptance rate on individual suggestions may drop, but the overall usefulness of the tool rises because the interface stops fighting the person who actually owns the outcome.
This is not a rejection of AI assistance. It is an application of Solomon’s discernment: surface the model’s proposal, then give the one closest to the child the uncomplicated ability to set it aside. The measure of a trust feature is not how often the suggestion is accepted. It is how little effort it takes for the right person to override it when acceptance would cause harm.
Your Turn: Apply This Today
- Open the current planning tool your team uses and locate the suggestion pane; add a one-click toggle labeled “Hide for this plan” directly beside it before the next release.
- Pick one children’s ministry volunteer who has used the tool in the past month and ask her to walk through her last planning session while you watch; note every time she ignored or dismissed a suggestion.
- Change the default state for new users in one small cohort so the suggestion pane starts hidden; measure whether they turn it on later compared with the always-on group.
- Write the override action into the user flow spec for the next AI feature so the engineering ticket includes the off-switch before any model integration work begins.
- Review the last three support tickets from ministry users about “bad suggestions” and trace whether each person had an easy path to disable the pane without leaving the screen.
- Set a recurring calendar reminder for the first Monday of each month to ask two frontline users whether the current suggestions still match what they actually have on hand.
The same pattern shows up in the work I described in The AI Line Item No Demo Ever Justified and The v1 Where the Model Handed Me the Safe Path.
I consult with product leaders building AI planning tools for ministry volunteers on suggestion interfaces, override controls, and frontline decision rights. Let’s talk.