Getting started
First orientation, trial expectations, and what to do next after initial setup.
TR-2529 bilingual help center
Help that is readable, grounded, and easy to escalate from.
This help-center tranche creates a launch-critical article inventory, a task-oriented category map, retrieval-ready article structure, and visible escalation paths that connect back into structured intake.
Launch help-center rules
- One clear topic per article.
- Visible escalation before frustration builds.
- Human-readable structure that is also reliable for later AI grounding.
- EN and ES parity tracked explicitly for launch-critical topics.
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.
First real Spanish help surface
A small Spanish help tranche is now live for a few highest-trust launch articles. It is intentionally partial rather than pretending the full help center is already equivalent.
Open Spanish help tranche →Launch-critical categories
The IA follows the help-center implementation brief and keeps the top-level map stable from the start.
People and households
Canonical people-record and household guidance for launch understanding.
Giving and billing
High-trust money explanations with clear separation between giving truth and SaaS billing truth.
Imports and migration
Realistic migration guidance, staging expectations, and what to do when the mapping is not obvious.
Roles, access, and security
Sign-in basics, permissions framing, and user-facing security expectations.
Reporting and exports
Definition-sensitive help for dashboards, reporting meaning, and data export basics.
Support, troubleshooting, and known issues
Recovery paths, common blockers, and when to escalate into structured intake.
Retrieval-ready writing rules
The article system should work for both human readers and future grounded support flows.
Required properties
- One clear topic per article
- Intent-shaped headings near the top
- Warnings and exception cases stated plainly
- Stable terminology and visible escalation triggers
What this prevents
- Mixed-topic walls of text
- Support macros pretending to replace canonical docs
- Weak AI grounding from vague or blended articles
- Trust drift between pricing, migration, and support surfaces
Article inventory
These articles now anchor every launch-default top-level category from the TR-2529 packet.
Getting started
First orientation, trial expectations, and what to do next after initial setup.
task walkthrough
Start your Transparent trial
Use the trial path when you want a calm, structured evaluation with clear next steps and no hidden annual-commitment framing.
Read article →policy rule
When early setup uncertainty is still normal trial-start friction vs a real blocker
Some early uncertainty is normal trial-start friction, but it becomes a real blocker when it starts weakening readiness confidence or making the next step unsafe to guess through.
Read article →faq
How to read readiness uncertainty without overclaim
Unclear readiness signals should stay visible as uncertainty, not get over-read as proof a church is unready or hidden proof that start certainty already exists.
Read article →escalation known issue
When a start-now question needs guided review
Start-now questions can stay ordinary for a while, but they need guided review once readiness ambiguity starts changing the safest path, stakeholder consequence, or migration-related confidence.
Read article →overview
How to route getting-started questions conservatively
The safest route depends on whether the question is still general getting-started interpretation or has become a consequence-heavy readiness, migration, or stakeholder question that needs narrower handling.
Read article →policy rule
When guided demo is still optional vs a real next-step blocker
Guided demo can stay optional for ordinary evaluation questions, but it becomes the safer next move once ambiguity starts changing whether self-serve trialing is still safe to trust.
Read article →overview
How to read evaluation-readiness uncertainty without overclaim
Evaluation-readiness uncertainty should stay visible and interpreted carefully, not over-read as proof that a church is either secretly unready or already cleared for guided certainty.
Read article →escalation known issue
When a self-serve path has outgrown broad help and needs guided review
A self-serve path can remain valid for ordinary evaluation, but it has outgrown broad help once route ambiguity or consequence becomes too church-specific for public interpretation alone.
Read article →overview
How to route demo and evaluation questions conservatively
Demo and evaluation questions should stay in broad help only while they remain general enough to interpret safely, then move into guided handling once the consequence becomes church-specific.
Read article →People and households
Canonical people-record and household guidance for launch understanding.
overview
People and household basics
People and households should stay clear, canonical, and reviewable so churches do not build messy record habits during launch.
Read article →policy rule
Duplicate and cleanup posture
Cleanup guidance should reduce record mess early without encouraging casual merges or overconfident household edits.
Read article →escalation known issue
Merge and change-risk boundaries
People-record changes should keep merge risk, relationship ambiguity, and real-data consequences visible instead of hiding them behind cleanup language.
Read article →policy rule
When people-data uncertainty is still normal cleanup friction vs a real blocker
Some people-data uncertainty is normal cleanup friction, but it becomes a real blocker when it starts weakening trust, changing merge confidence, or making the next step unsafe to guess through.
Read article →faq
How to read duplicate or household ambiguity without overclaim
Unclear duplicate or household signals should stay visible as ambiguity, not get over-read as proof of bad data or hidden proof that record certainty already exists.
Read article →escalation known issue
When shared household or record-identity ambiguity needs guided review
Household or identity questions can stay ordinary for a while, but they need guided review once the ambiguity starts changing canonical meaning, merge safety, or real people-history consequence.
Read article →overview
How to route people and households questions conservatively
The safest route depends on whether the question is still general people-data interpretation or has become a consequence-heavy identity, household, or merge question that needs narrower handling.
Read article →Giving and billing
High-trust money explanations with clear separation between giving truth and SaaS billing truth.
policy rule
Pricing, trial, and hardship basics
Transparent launch pricing is month to month, begins with a two-month free trial, and keeps hardship visible without turning it into hidden pricing negotiation.
Read article →policy rule
Canonical pricing meaning vs help explanation
Help can explain pricing posture, but it should not become a shadow quote, contract, or account-specific promise stronger than the governed pricing surface.
Read article →policy rule
How hardship posture should be read
Hardship should be understood as a visible manual review path, not as hidden bargaining, automatic discounts, or guaranteed pricing outcomes.
Read article →overview
When a billing question is account-specific
Some billing questions stay at the public explanation layer, but others cross into account-specific territory and should stop using generic help as the main path.
Read article →faq
How to route a money-sensitive question
Money-sensitive questions may belong in public help, billing or pricing intake, hardship intake, or broader support, and the safest route depends on what kind of ambiguity you actually have.
Read article →Imports and migration
Realistic migration guidance, staging expectations, and what to do when the mapping is not obvious.
overview
Prepare for import and migration review
Migration guidance should be realistic, staged, and explicit about what still needs human review.
Read article →task walkthrough
Migration readiness checklist
Use a simple readiness checklist before guided migration review so expectations stay grounded in real exports, real owners, and real cleanup questions.
Read article →policy rule
Record mapping and field-review boundaries
Migration help should explain mapping boundaries clearly so churches do not confuse guided review with automatic field certainty.
Read article →policy rule
When migration ambiguity is still okay vs a real blocker
Some migration uncertainty is normal evaluation friction, but it becomes a real blocker when it starts changing decisions, weakening stakeholder confidence, or making the trial insufficient.
Read article →faq
How to read data-mapping uncertainty without overclaim
Open mapping questions should stay visible as uncertainty, not get over-read as proof of failure or hidden proof that migration certainty already exists.
Read article →task walkthrough
When cleanup uncertainty needs guided review
Some cleanup work is ordinary migration preparation, but cleanup uncertainty needs guided review when it starts changing confidence, scope, or whether the migration question can still be answered safely.
Read article →overview
How to route migration-certainty questions conservatively
The safest route depends on whether the question is still general migration interpretation or has become a consequence-heavy certainty question that needs guided review.
Read article →Roles, access, and security
Sign-in basics, permissions framing, and user-facing security expectations.
overview
Sign-in, access, and security basics
User-facing security guidance should stay clear about access boundaries and avoid vague reassurance.
Read article →task walkthrough
Requesting and approving access changes
Access-change guidance should keep requesters, approvers, and sensitive follow-up paths explicit so permissions do not drift by assumption.
Read article →escalation known issue
Sensitive access and identity escalation rules
Identity and permissions edge cases should route into narrower, reviewable handling instead of relying on reassurance or guessed authority.
Read article →policy rule
When access uncertainty is still okay vs a real blocker
Some access uncertainty is normal setup friction, but it becomes a real blocker when it starts changing trust, approval decisions, or whether the next step is safe to take.
Read article →faq
How to read approver or delegated-access uncertainty without overclaim
Unclear authority claims should stay visible as uncertainty, not get over-read as proof of bad intent or hidden proof that verification certainty already exists.
Read article →task walkthrough
When shared access or identity ambiguity needs guided review
Some shared-access questions are ordinary clarification, but identity or shared-access ambiguity needs guided review when it starts changing safety, trust, or whether the next action can be taken responsibly.
Read article →overview
How to route roles, access, and security questions conservatively
The safest route depends on whether the question is still general access interpretation or has become a consequence-heavy authority or identity question that needs narrower handling.
Read article →Reporting and exports
Definition-sensitive help for dashboards, reporting meaning, and data export basics.
faq
Reporting and export basics
Reporting help should explain what numbers mean without creating a second source of truth or fuzzy export expectations.
Read article →policy rule
Canonical reporting value vs help explanation
Help can explain reporting meaning, but it should not become a second source of truth stronger than the product surface itself.
Read article →faq
How to read an export safely
Exports are governed handoff paths, not casual dumps or automatic proof that every downstream interpretation is already normalized.
Read article →overview
When a reporting question is low risk
Some reporting questions are still low-risk interpretation questions that can stay in governed help or ordinary verification without immediate escalation.
Read article →escalation known issue
When reporting ambiguity needs escalation
A reporting question needs escalation when definition uncertainty or value interpretation becomes serious enough to affect a real decision.
Read article →faq
How to route a reporting ambiguity question
Reporting ambiguity may be an explanatory question, a canonical-value concern, a known limit, or a support issue, and the safest route depends on which kind of ambiguity you are actually facing.
Read article →Support, troubleshooting, and known issues
Recovery paths, common blockers, and when to escalate into structured intake.
escalation known issue
Support and escalation paths
Use self-serve help first when it answers the question, then move into structured intake before frustration compounds.
Read article →troubleshooting
Trial and migration known limits
Some launch-surface answers remain orientation-first, so this article makes the known limits explicit instead of letting confidence drift too far.
Read article →overview
Choose your support path
Use the shortest support path that still keeps the question grounded, safe, and appropriately routed.
Read article →policy rule
When grounded self-serve is enough
Some support questions are still safe for governed self-serve help, while others need routed follow-up before confidence drifts too far.
Read article →task walkthrough
Report a blocked task clearly
A good blocker report should show what you were trying to do, what you already tried, and why the consequence matters.
Read article →escalation known issue
When to stop retrying and escalate
Some support issues improve with one more careful attempt, but others should escalate before more self-serve effort creates noise or risk.
Read article →faq
Support routing categories explained
Category-first routing exists so the question reaches the safest review lane without turning support into one noisy inbox.
Read article →faq
Bug report vs feature request
The difference matters because broken behavior and missing capability usually need different review posture from the start.
Read article →policy rule
Sensitive support topics and escalation
Some support questions should narrow quickly into safer handling because the risk is in the consequence, not just the confusion.
Read article →faq
Expected limit vs likely bug
Some product gaps are current boundaries, while others look broken enough that they should be treated as likely bugs instead of normal limits.
Read article →policy rule
Current scope vs future possibility
Present product truth should stay separate from future possibility so launch guidance does not quietly turn into roadmap implication.
Read article →overview
When a known limit is still okay
Some known limits are real, but still compatible with safe trial progress when they do not block the main decision your church is trying to make.
Read article →escalation known issue
When a known limit becomes a real blocker
A known limit becomes a real blocker when it starts reducing migration confidence, launch readiness, or trust in whether Transparent can support the workflow you actually need.
Read article →faq
How to route a product-gap question
A product-gap question may point to a known limit, support issue, bug suspicion, or feature request, and the safest route depends on what kind of gap you are actually seeing.
Read article →task walkthrough
What a good support follow-up update looks like
A useful follow-up should add new signal, changed consequence, or clarified context instead of restarting the whole support story from zero.
Read article →policy rule
When to wait vs when to follow up again
Sometimes waiting is still the safer move, and other times changed consequence or new signal makes another follow-up the better choice.
Read article →overview
How to carry forward context without repeating everything
Good follow-up context should preserve what matters now without turning each update into a full copy of the entire issue history.
Read article →faq
How to read support progress conservatively
Acknowledgment, routing, and partial updates are useful signals, but they should not be over-read as proof of hidden workflow maturity or outcome certainty.
Read article →Ownership and parity posture
Canonical help should stay governed instead of drifting into unowned support text.
Every launch article should carry
- Article owner
- Parity reviewer
- Last reviewed date
- Source-of-truth status
Review rule
When user-visible behavior changes, the matching help article should be reviewed deliberately instead of leaving support, pricing, or migration explanations to drift behind the product.
Need more than an article?
Support should stay calm and explicit about the safest next step.
Self-serve first
Use articles when you need trial, pricing, migration, or launch-surface orientation without sharing extra context.
Open the trial path →Review getting-started sequence →Ask grounded support first
Use the bounded assistant when a governed help article may answer the question and you want visible sources.
Open support assistant →Escalate with structure
If the question is blocked, sensitive, billing-related, or otherwise needs a routed case, use structured intake instead of a catch-all contact path.
Open structured intake →Billing or pricing route →Hardship route →