TTransparentLaunch public shell

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 →

Support or troubleshooting issue

Use this when help content or the assistant did not fully resolve a blocked task.

Routes to normal support triage first, with escalation if the issue becomes sensitive or unresolved.

Bug report

Use this when something appears broken and you want support to capture it clearly for review.

Routes to support triage first, then onward after normalization if engineering review is needed.

Feature request

Use this when the main issue is a product gap rather than a broken workflow.

Routes to product review with a calmer, structured problem statement.

Billing or pricing question

Use this for account-sensitive pricing, invoice, or trial questions that should not sit in broad support chatter.

Routes to a restricted billing path with minimum-necessary visibility.

Restricted-path review by default

Hardship request

Use this for affordability concerns when you need a humane and low-anxiety route.

Routes to a restricted hardship review path and does not require deep financial detail up front.

Restricted-path review by default

Sales or demo request

Use this when the real need is guided evaluation, migration review, or stakeholder alignment.

Routes to the evaluation/demo lane rather than the active support queue.

Structured intake

Share a feature request

Use this path when the main issue is a product gap or missing workflow, not a broken experience.

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: product review should preserve the desired outcome, dedupe related asks, and avoid treating the support inbox like an idea dump.

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