Business Questions Correction - G33-Moviles-2026-1/Wiki GitHub Wiki
Type 1 — App telemetry
Which feature/flow has the highest crash rate (crashes per 1,000 sessions): Search, Filters, Schedule Suggestions/My Gaps, Report Occupied, Favorites, Room Details, Reserve/Chatbot? Rationale/decision: prioritize hotfixes where the app fails most during time-sensitive moments and improve perceived stability.
On which screens/actions does p95 latency (response time) exceed the target threshold (e.g., 1s/2s) during peak hours? Rationale/decision: optimize “few taps / fast discovery” when users are walking and in a hurry.
How do crashes/errors distribute by context (device model/OS, weak connectivity, location permission denied), and which flow breaks first? Rationale/decision: design graceful degradation (no-location mode, caching, “last updated”) and reduce churn caused by indoor limitations.
Type 2 — Direct user experience improvement
For a user near a building (or with approximate location), what are the top N “Available now” rooms ordered by estimated walking time, including the room status last-updated timestamp? Rationale/decision: reduces wandering time and increases trust with timestamps.
For a user, which available rooms match a specific gap based on capacity/equipment? Rationale/decision: turns the users needs into actionable recommendations (“My gaps and intentions” → “Recommended Rooms”).
For each room shown as available, what is its reliability level (e.g., Scheduled Free, User-validated, Conflicting reports) and when was it last validated? Rationale/decision: delivers direct value by making uncertainty visible and increasing user confidence (instead of “accuracy” only for analytics).
For a specific room, which verifiable utilities does it have: equipment (projector/computer), power outlets/chargers availability, space type, Big tables? Rationale/decision: supports fast decisions for studying/resting/group work without “insider knowledge”.
Type 3 — Feature analysis
Which filters (building, floor, capacity, equipment) are applied most often, and in what sequence (e.g., building → capacity → equipment)? Rationale/decision: simplify UI (defaults, quick filters) and reduce taps when users are in a rush.
What characteristics do the most favorited rooms share (building/location, capacity, equipment, proximity to frequently visited class buildings, real availability history)? Rationale/decision: improve recommendations (stronger priors) and suggest “similar rooms” that actually help users.
What is the most common way users upload/import their schedule (Google/Apple Calendar sync, ICS/PDF file, manual), and which method has the highest drop-off by step? Rationale/decision: invest in the winning method and remove friction in the losing one (permissions, formats, UX).
What percentage of users rely on Recommended Rooms (location + gaps) vs manual search, and which path reaches “room selected” faster (time to success)? Rationale/decision: validate whether the recommendation engine reduces time/stress or needs recalibration.
Type 4 — Benefits from data
Where are the demand hotspots (searches/views/intent-to-reserve) by building + time window, and how do they compare to official occupancy? Rationale/decision: identify overcrowding, rebalance resources, and inform space policies.
Which rooms/zones have the most mismatches (“shown free” but users report occupied), and what is the average correction/update latency until the status becomes accurate? Rationale/decision: improve real-time validation and increase trust in availability signals.
Type 5 - Mixed
On which screens/navigation segments do users spend the most time before completing a key action (select room / navigate to room / reserve), and how does that time correlate with success outcomes and user satisfaction signals (e.g., fewer mismatch reports, more rooms selected)? Rationale/decision: place ads where they don’t break urgent flows, improving revenue and UX.
Which context combination (peak hour, weak connectivity, no location, short gaps) most changes recommendation effectiveness and abandonment? Rationale/decision: personalize fallbacks (no GPS, caching, defaults) and decide where engineering effort matters most.