Let's Resolve Your Rideshare Issue

Please remove this app support form insights section before publishing.

This form is meticulously designed to transform a vague user complaint ("The app isn't working!") into a structured, actionable ticket for a support team. Its effectiveness lies in its logical progression, which mirrors a technical support troubleshooting methodology.

1. Section 1: Your Information & Account Details

• Purpose: To immediately identify the user and access their account in the database.
• Key Insights:
• • Email Address: This is the primary key for locating the user's account and the main channel for follow-up communication. Mandatory field.
  • Account Type (Rider/Driver): This is the single most important filter. The backend systems, data views, and even support teams for riders and drivers are often completely separate. A driver's issue with navigation is fundamentally different from a rider's issue with payment. This question instantly routes the ticket to the correct queue.
  • "First time use?" This simple question is a powerful diagnostic tool. If "Yes," the issue is more likely to be user error, a misunderstanding of the app flow, or a sign-up/verification problem. If "No," it points more strongly to a bug, regression, or account-specific problem.

2. Section 2: Categorize Your Issue

• Purpose: To perform high-level triage and automate ticket routing.
• Key Insights:
• • This is a multi-choice single-select to force the user to think about the core problem. The categories are mutually exclusive by design to avoid confusion.
  • "Login & Account Access" routes to an authentication/security team.
  • "Booking a Ride" / "During a Ride" / "Payment" route to the core customer/driver support ops team.
  • "Technical Problem" is a critical category. This is the red flag that gets routed directly to the engineering or quality assurance (QA) teams. It signals a potential bug rather than a service issue.
  • "Driver-Related Issue" or "Safety Concern" would be high-priority tickets, potentially routed to a dedicated safety and compliance team with specialized training.

3. Section 3: Detailed Description of the Problem

• Purpose: To get a narrative context that structured fields cannot capture.
• Key Insights:
• • "What were you trying to do?" establishes the intended user goal.
  • "What happened instead?" describes the actual, faulty outcome. The gap between these two answers is the very definition of the bug or issue.
  • "Quote error messages exactly" is crucial. Error messages often contain unique codes that correlate directly to specific failures in the server logs, dramatically speeding up investigation.
  • Date/Time and Frequency are critical for correlation. If 1000 users report the same bug for a specific 10-minute window, it points to a server-side outage or a third-party API (like maps or payments) being down. A "one-off" issue is more likely to be local to the user's device or account.

4. Section 4: Specific Incident Details

• Purpose: To directly query the database for the exact event in question.
• Key Insights:
• • Trip ID is the golden ticket. Every ride generates a unique identifier in the database. With this ID, a support agent can instantly pull up every piece of data associated with that trip: GPS trace, driver info, transaction record, timestamps, and communication logs. It makes investigating pricing, route, or driver issues nearly instantaneous.
  • Without this, the agent must search using fuzzy details (email, approximate time, route), which is slow and error-prone.

5. Section 5: Technical & Device Information

• Purpose: To identify patterns and root causes related to the software and hardware environment. This section is non-negotiable for app support.
• Key Insights:
• • App Version: A bug might exist in version 4.21.0 but was already fixed in 4.22.0. The first response might be "Please update your app." Conversely, if a new bug is reported by many users on the same new version (e.g., 5.0.0), it flags a critical regression.
  • OS Version: A new iOS or Android update might break a feature in the app. Problems are often specific to certain OS versions (e.g., "This bug only occurs on Android 13").
  • Device Model: Problems can be hardware-specific. For example, an app might crash on a specific phone model due to a driver compatibility issue or screen resolution quirk.
  • The Troubleshooting Checklist: This serves two purposes:
  • 1. It empowers the user: They might solve the problem themselves by simply restarting their phone.
    2. It sets a baseline: The support agent knows what has already been tried and won't waste time asking the user to do it again. If all steps are checked, the problem is almost certainly more severe and requires deeper investigation.

6. Section 6: Attachments

• Purpose: To provide irrefutable visual evidence of the issue.
• Key Insights:
• • A screenshot can show a frozen UI, a misdisplayed price, or a blank map.
  • A screen recording is invaluable. It can show the exact sequence of taps that leads to a crash, the erratic behavior of a UI element, or the real-time struggle with a unresponsive button. It often reveals user error or unexpected app behavior that the user wouldn't think to describe in text.

7. Section 7: Contact Preferences & Follow-up

• Purpose: To manage customer expectations and ensure efficient communication.
• Key Insights:
• • Respecting the user's preferred contact method and time increases the chance of a successful first contact and improves overall customer satisfaction.

Overall Strategic Advantages of This Form:

1. Dramatically Reduced Resolution Time (MTTR): By collecting 90% of the necessary diagnostic information upfront, it eliminates the need for 3-4 back-and-forth emails between the user and support. A ticket arrives already pre-qualified and rich with data.
2. Pattern Recognition and Proactive Fixes: When all tickets are structured this way, data analytics becomes powerful. The support team can easily generate reports: "35% of our 'Payment' tickets in the last week are for promo code failures on iOS version 4.21.0." This data is fed directly to product and engineering teams to prioritize fixes.
3. Improved User Experience: While the form seems long, it actually creates a faster and less frustrating experience for the user. They explain their problem once, in detail, rather than being asked repeatedly for more information over several days.
4. Efficient Resource Allocation: Automated triage (based on Account Type and Issue Category) ensures tickets are handled by the most qualified team immediately.

In essence, this form is not just a collection of fields; it's a finely tuned instrument for diagnosing digital problems in a complex, two-sided marketplace application. It translates user frustration into structured, technical data that a support and engineering team can act upon.

Please remove this mandatory questions recommendation before publishing.

Mandatory Questions & Elaboration

1. Email Address (linked to your account)

• Why Mandatory: This is the primary key for the entire support process.
• Elaboration:
• • Account Identification: It is the most reliable way to locate the user's account in the database to view their trip history, payment methods, and account status.
  • Communication Channel: The support team must have a way to respond to the user. Without an email, the ticket is a dead end. It's also used for sending automated updates on the ticket's status.
  • Verification: It acts as a first step in verifying the user's identity for security purposes, especially when discussing account-specific details.

2. Account Type: [ ] Rider [ ] Driver

• Why Mandatory: This is the single most important piece of context for triage.
• Elaboration:
• • Different Systems, Different Teams: The backend data, the app features, and the support teams for riders and drivers are completely separate. A rider's issue with a receipt and a driver's issue with their earnings are investigated in different systems by different specialized agents.
  • Routing Efficiency: This field automatically routes the ticket to the correct support queue instantly. A ticket from a driver sent to the rider support team would waste significant time and require manual reassignment, delaying resolution.

3. Please select the category that best describes your issue:

• Why Mandatory: This is the primary tool for triage and prioritization.
• Elaboration:
• • Team Specialization: Like the account type, this ensures the ticket goes to an agent or team trained to handle that specific problem (e.g., payment experts, safety specialists, technical bug triage).
  • Priority Setting: Categories like "During a Ride" or "Safety Concern" can be automatically flagged as high priority, requiring an immediate response. A "General Feedback" ticket can be handled with a lower priority.
  • Initial Diagnosis: The category sets the context for the agent before they even read the description, priming them to look for specific solutions.

4. Please describe the issue you are experiencing in detail:

• Why Mandatory: The structured data is useless without narrative context.
• Elaboration:
• • The "Why" and "How": While other fields answer "who," "what," and "when," this field answers "what happened?" and "how did it happen?" It provides the story behind the error codes and timestamps.
  • User Intent: It reveals what the user was trying to do, which is often key to understanding if the issue is a bug, a design flaw, or user error.
  • Error Messages: This is the most likely place a user will paste a specific error message, which is often the direct key to finding a solution in knowledge bases or bug databases.

Conditionally Mandatory Questions

These questions should become mandatory if the user selects a related category in Section 2. This is a best practice in form design to reduce friction for users whose issues don't require this information.

5. Trip ID / Confirmation Number (Mandatory if user selects any ride-related category, e.g., "Booking a Ride," "During a Ride," "Payment & Pricing")

• Why Conditionally Mandatory: For ride-specific issues, this is the most efficient way to find the exact event in the database.
• Elaboration:
• • Direct Database Query: The Trip ID is a unique key. With it, an agent can pull up the complete record of that trip—GPS route, driver info, surge pricing multipliers, transaction ID, and timestamps—in seconds.
  • Without It: Without the Trip ID, the agent must search using fuzzy details (email, approximate time, pick-up location), which is slow, inefficient, and prone to error, especially in dense urban areas with thousands of concurrent rides.

6. App Version Number (Mandatory if user selects "Technical Problem")

• Why Conditionally Mandatory: This is the first question for any suspected bug.
• Elaboration:
• • Version-Specific Bugs: Bugs are often isolated to a specific version of the app. A problem might be a known issue fixed in a later update, or a new bug introduced in the latest release.
  • Reproduction: For engineers to investigate a bug, they must know which version of the codebase to look at. Without this, debugging is nearly impossible.

Why Other Key Questions Are Not Mandatory

• Phone Number: While useful for urgent or complex issues, not all problems require a call. Many users are wary of providing a phone number and prefer email-only support.
• Device & OS Information: While extremely valuable, making it mandatory creates a barrier for non-technical users who may not know how to find this information. It's better to strongly encourage it (e.g., with helpful text like "This info is crucial for technical issues") rather than force it for a payment or account question.
• Screenshots: Again, highly encouraged but not mandatory for every issue (e.g., "I forgot my password" doesn't need a screenshot).