Pattern 67
A support route has a real owner
Make human contact, confidentiality and safeguarding responsibilities explicit.
Concrete takeaway
Distinguish user-initiated contact from an actual staffed transfer and state availability, eligibility and what data would be shared.
Choose an approach
These are editorial decision conditions to validate. Some alternatives are successive states or can be combined; they are not always exclusive choices.
| Alternative | Use when | Tradeoff or requirement |
|---|---|---|
| A · Contact information | The product only offers contact information | Do not label a link as a transfer |
| B · Real staffed transfer | An actual staffed transfer is operational | Confirm data, recipient, eligibility and expected wait |
| C · Service unavailable | A staffed route is unavailable | Show real alternatives without claiming someone is watching |
The problem
A chatbot can display a support button without staffing, send disclosures to an unsafe recipient or promise confidentiality beyond its actual policy.
The pattern
Distinguish user-initiated contact from an actual staffed transfer and state availability, eligibility and what data would be shared. Give control over a proposed summary and recipient where applicable. Do not default to a parent, partner or church leader who could be implicated. Services for minors and vulnerable people need specialist-designed pathways and jurisdiction-specific review of confidentiality, reporting and organisational duties. Explain applicable limits without claiming universal rules or sending reports that the product cannot deliver. Immediate help must not depend on an export or polished summary.
Compare the alternatives
Make human contact, confidentiality and safeguarding responsibilities explicit.
A · Contact information
A link is accurately labelled as user-initiated contact.
B · Real staffed transfer
Only an operational service can promise a transfer.
C · Service unavailable
A failed route does not imply someone is watching.
Original wireframe proposals · No live controls · Grey rows represent schematic text, not loading states · Labelled placeholders are not Scripture quotations
Download this wireframe as SVGFailure modes
Fake warm transfers; silently sending transcripts; blanket secrecy promises; unsafe guardian routing; treating a contact card as proof that someone is responding.
What to validate
Test staffed and unstaffed hours, declined sharing, unavailable services, unsafe recipients and age-appropriate scenarios. Verify responsibilities before launch, not only button behaviour.
Sensitive design proposal · Safeguarding review required. These visual alternatives have not been tested with users in this atlas. Source findings, documented behaviour and this proposed adaptation are different kinds of evidence.
Sources and adaptation
This card is an original design synthesis. The following sources inform its content distinctions, interaction approach or review requirements; they do not validate the whole pattern.
- Caring for women subjected to violence: health-care provider curriculumOfficial curriculum overview reviewed; full training materials not reviewed · Clinical training for human providers focused on violence against women; transfer to other populations or AI requires separate review.
- Ruth AI Chatbot FAQProvider FAQ reviewed on 5 October 2026 · Provider documentation, not independent safety or efficacy evidence; no assumption that another product shares its safeguards.
- Process personal data lawfullyOfficial guidance reviewed · Specific lawful basis, retention and DPIA decisions require the actual data flows.
- Psychological first aid Guide for field workersOfficial guide overview reviewed · Designed for human helpers, not authorisation of autonomous AI crisis care.
Common scenarios and flows
- Respond to a sensitive disclosure with accountable support — Keep disclosure, present safety, user choice and service responsibility distinct.
Design principles in this decision
Editorial application of Missional by Design. These values frame review questions; they do not validate a pattern’s effectiveness.
- Reverence — What does this interaction ask of the person, and can they understand, decline, correct or leave it without penalty?
- Bridge — What does this experience enable beyond the session, and is the next step voluntary, accessible and safe?
- Costliness — Who pays for this convenience through time, labour, privacy, risk or exclusion, and can the organisation support its promise?
Compare alternatives using the task and evidence above. Record competing needs instead of treating a principle as an automatic verdict.
Regional applicability
Design review questions · 5 October 2026. These prompts identify possible triggers; they do not classify this pattern or every faith app as a regulated service.
Could functionality, marketing or reasonable expectations make this a companion or mental-health service? Define the human role, health claims, escalation capability and locally verified support route before selecting dialogue UI.
Start with EU and Germany, then review the relevant market:
- US · California — Enacted AI-specific law
- US · New York — Enacted AI-specific law
- US · Utah: mental-health chatbots — Enacted AI-specific law
- US · Illinois — Enacted AI-specific therapy restrictions
- US · Texas — Enacted AI-specific law; effective 1 January 2026
- US · Federal health software and data — Existing law; regulator implementation guidance
- United Kingdom — Existing law + regulator guidance; policy statement
- Australia — Existing law + regulator guidance; national policy
Use the jurisdiction decision guide to record the trigger, source version and resulting product requirement.