low complexity extracted Help & Support Confidence: 100%
2
Components
39
Shared
0
User Stories
Yes
Analyzed

Description

The Contact Us feature provides peer mentors and coordinators with a direct channel to reach support when they encounter problems, have questions, or need assistance with the platform. The screen presents contact options appropriate to the user's context, such as email, phone, or an in-app support request form, and routes the request to the correct support team. The feature is always accessible regardless of which modules are enabled for the user's organization. Support requests are submitted with optional metadata (app version, device, role) to help the support team diagnose issues faster. Submitted requests generate a confirmation with a reference number so users know their message was received. The screen is intentionally minimal to remain usable even when the user is confused or frustrated.

Analysis

Business Value

A visible and accessible support channel is foundational to user trust, particularly for peer mentors with limited digital confidence. Without it, blocked users abandon workflows silently rather than reporting problems, leading to underreporting and frustration that erodes adoption. For Norse Digital Products, capturing support requests in-app rather than through informal channels (WhatsApp, email to coordinators) produces structured data about recurring issues and allows prioritization of fixes. From an organizational perspective, each support interaction that is routed correctly reduces the burden on coordinators who otherwise absorb platform questions informally. Keeping this feature always-on and outside the module toggle system ensures no configuration mistake can accidentally leave users without a help path. The low implementation cost relative to the trust and retention benefit makes this a clear MVP inclusion.

Implementation Notes

Implemented as a static Flutter screen with a `SupportRequestService` that POSTs to a lightweight backend endpoint. The form collects an optional message and attaches device metadata (platform, OS version, app version, user role) automatically - no user action required for diagnostics. The backend endpoint forwards to the support ticketing system (email or a future helpdesk integration) and returns a reference number stored locally for display. Because this screen must be reachable even when auth tokens are expired, the support endpoint accepts unauthenticated requests with a rate-limited public key. The UI uses standard design-token classes and accessible form widgets from the shared widget library. WCAG 2.2 AA compliance is verified through the Accessibility Audit CI step. No offline queue is needed - if the request fails, the user is shown a retry prompt with the support email address as a fallback.

Components (41)

User Interface (1)

Service Layer (1)

Shared Components

These components are reused across multiple features

User Stories

No user stories have been generated for this feature yet.