Step 1
Welcome and orientation
Start with a calm explanation of what onboarding will and will not do. The goal is progress without pretending everything must be configured at once.
TR-2531 onboarding and launch docs
Getting started should feel guided, calm, and explicit about what comes next.
This first onboarding slice is intentionally a launch-doc and sequence shell, not a fake full wizard. It makes the first-run path clearer now, while keeping AI advisory, migration-aware, and bounded by explicit approval for high-risk actions.
Onboarding rules
- Guided, not pushy
- Migration-aware, not migration-assuming
- AI-assisted, but advisory only
- Explicit about what is safe now versus later
Recommended first-run sequence
The launch shell should reduce confusion by sequencing good decisions, not by pretending everything can be auto-handled.
Step 2
Account and access basics
Access should be deliberate from the start. Onboarding can explain roles and setup posture, but it should not encourage casual permission expansion just to move faster.
Step 3
Church profile and initial setup context
Focus first on the small set of foundational setup decisions that make later work easier. Leave advanced configuration for later instead of front-loading everything.
Step 4
Pricing, trial, and evaluation expectations
Keep the month-to-month posture, two-month trial, hardship visibility, and guided-help option visible before a church builds the wrong expectations.
Step 5
Choose a migration path
Make import now versus later explicit. Migration help should be honest about staging and review instead of implying one-click perfection.
Step 6
Prepare imports or defer safely
Churches should be able to keep learning without being forced into full migration immediately. If importing, the path should stay staged, reviewable, and explicit.
Step 7
Set up the first core workflow
Show a small, high-value setup sequence with clear optional versus required boundaries. Avoid sprawling setup checklists and feature-tour fluff.
Step 8
Know the next safe step
After onboarding, the church should know what is safe to do now, what should wait, and when to escalate to human help instead of guessing.
AI guidance stays advisory
Transparent should feel smart by reducing confusion, not by taking consequential decisions out of the church’s hands.
AI may help with
- Explaining each setup step
- Recommending grounded next steps
- Clarifying migration preparation
- Surfacing relevant help-center articles
AI must not do
- Silently change settings with meaningful consequences
- Commit imports or finalize mappings without explicit approval
- Broaden permissions automatically
- Invent trust, billing, or security answers outside grounded docs
High-risk approval map
Some actions should be prepared by onboarding, but never casually executed through it.
High-risk action classes
- Permission or role changes
- Import approval and canonical commit
- Billing or subscription-affecting actions
- Public-surface or publish-affecting actions
- Sensitive data export or sharing actions
Boundary rule
Onboarding may explain these actions and help a church prepare for them, but the product should show plain-language consequences and require explicit operator approval before commit.
Current bilingual launch posture
The current public launch shell is English-first. Spanish parity remains an explicit review and implementation task for trust-sensitive surfaces, so no Spanish path should be implied equivalent until it is rechecked and landed.
- Current live launch shell content is English-first.
- Spanish parity is still in progress for trust-sensitive launch surfaces.
- Do not imply equivalent EN/ES launch readiness until the specific surface is re-reviewed and landed.
Current shell boundaries
This keeps the page truthful about what has landed already and what still belongs in later implementation work.
What this page is
A calm launch-shell sequence that explains the first-run path, advisory AI boundaries, migration-aware choices, and explicit approval classes.
What is not yet real
- This is not yet a stateful onboarding wizard with saved progress.
- It does not yet connect to real account-state or completion tracking.
- It does not commit imports, broaden permissions, or publish anything on a church’s behalf.
Launch docs family
The first documentation set should extend onboarding, not drift away from it.
Getting started with Transparent
A calm launch-shell sequence that explains the first-run path, advisory AI boundaries, migration-aware choices, and explicit approval classes.
Open launch doc →Your first week in Transparent
A short launch checklist that separates immediate evaluation decisions from actions that should wait for explicit review.
Open launch doc →If you are unsure, choose the safer path
The onboarding shell should keep support and escalation obvious before a church gets stuck.
Need canonical guidance?
Use launch help content when you want the governed explanation first.
Browse help center →Need a grounded answer?
Use the assistant when a launch help article may answer the question quickly.
Open support assistant →Need routed follow-up?
Use structured intake when the issue is blocked, sensitive, or better handled as a case.
Open structured intake →