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

Billing or pricing question

Use this path for account-sensitive trial, invoice, or pricing questions that should route more narrowly than general support.

Avoid sharing payment details, full financial records, or other sensitive billing data in free text. This path exists so pricing and billing context can stay narrower by default.

Review pricing

What happens next: a restricted billing reviewer can follow up with minimum-necessary visibility. More information may be requested later, but you do not need to dump payment detail here.

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