Support Intake Form for Faster Triage

You are improving an existing product surface for this audience: Support, CX, and product teams improving contact or help-center intake.
Do not redesign the whole product. Add or refine only the form, survey, widget, or intake flow described here, and preserve the current brand, layout system, components, typography, color tokens, spacing scale, icon style, and content voice unless a change is required for usability or accessibility.

Goal:
Improve an existing support or contact form so users can submit a complete request once and support teams receive enough structured information to route and prioritize it.

Existing context to inspect first:
- Identify the current primary task, where the user has just come from, and what they still need to do after this form or feedback moment.
- Reuse existing form controls, buttons, field validation patterns, banners, sheets, dialogs, toasts, loading indicators, and analytics/event naming where available.
- Keep the visual treatment subordinate to the task. The enhancement should feel native to the current app or site, not like a pasted-in third-party widget.

Layout and content hierarchy:
- Start with a concise heading that sets expectations for response time and what information helps support respond faster.
- Use grouped sections for issue type, affected product area, urgency, subject, description, steps already tried, account/workspace context, attachments, and contact preference.
- Use progressive disclosure: show specialized fields only after issue type or urgency makes them relevant.
- End with a confirmation preview that summarizes the ticket category, urgency, and contact path before submission when the flow is long.

Interaction behavior and states:
- Pre-fill known account, workspace, browser, plan, and product-area metadata when available, but show sensitive captures for confirmation or consent.
- Adapt helper text by issue type so billing, bug, login, data, and feature questions ask for the right evidence.
- Show routing feedback after submit: ticket number, expected response window, next steps, and self-serve links that match the selected issue type.
- Preserve all user input after validation or network errors.
- Include these states with explicit UI copy and behavior: initial, issue type selected, conditional fields shown, file uploading, validation error, submitting, submitted, network retry, duplicate detected.

Mobile and responsive behavior:
- Use a single-column form with section anchors or a short stepper if the form exceeds one mobile screen.
- Keep file upload, contact preference, and submit actions reachable after the keyboard opens.
- On small screens, collapse secondary guidance into helper text and keep urgent support pathways visible.

Accessibility requirements:
- Use persistent labels, fieldsets for related radio/checkbox groups, and clear required/optional indicators.
- Provide an error summary that links to invalid fields and put focus where users can recover efficiently.
- File uploads need keyboard-accessible controls, allowed format/size guidance, and upload progress text.
- Urgency indicators cannot rely on color alone and must include plain-language definitions.

Implementation constraints:
- Map issue type and urgency to existing ticket queues, tags, SLAs, or notification rules.
- Limit required fields to what changes triage quality; make screenshots, logs, and phone number optional unless required by the issue type.
- Emit analytics for form start, issue type, upload added, validation error, abandon, submit, and duplicate suggested.
- Include spam/rate-limit handling without adding inaccessible CAPTCHA as the default path.

Quality checklist before finalizing:
- The form asks for enough context to route support without becoming a generic questionnaire.
- Conditional fields reduce effort instead of hiding required surprises after submission.
- Validation preserves user input and explains recovery steps.
- The success state sets expectations with ticket ID, response time, and next steps.
- The design reuses existing support, form, and alert components.

Output format:
- Return the proposed UI as an implementation-ready brief or code update appropriate to the existing project.
- Include component structure, field labels, validation copy, success/error copy, analytics events, responsive behavior, and handoff notes.
- Do not use placeholder text, fake image boxes, a new design system, a new framework requirement, or broad phrases like "make it modern".