TR-2530 structured support routing

Choose the shortest path that still routes your question safely.

This intake layer is intentionally category-first. It avoids catch-all contact chaos, keeps sensitive questions narrower by default, and gives future reviewers a cleaner routing object from the start.

A real Spanish structured-intake page is now available for this route. Open Spanish structured intake →

Structured intake

Request a demo

Use this path when your church wants guided evaluation, migration context review, or stakeholder alignment before trialing deeply.

Keep payment, identity, and other sensitive detail out of broad free text unless the form explicitly calls for it.

Open help center

What happens next: this routes into the evaluation/demo lane rather than the active support queue. If you want governed orientation first, you can still use the help center or support assistant.

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.

Routing rules at a glance

These paths are intentionally separated so support, evaluation, billing, and hardship context do not collapse into one noisy inbox.

General visibility lanes

  • Support or troubleshooting
  • Bug reports
  • Feature requests
  • Sales or demo requests

Restricted lanes

  • Billing and pricing questions with account-sensitive context
  • Hardship requests
  • Later security, privacy, or identity-sensitive paths as needed