Repository navigation
MS4
It's well known that Los Andes University's parking lots are limited, all potential users (specially students), have to make long lines and wait tens of minutes for being able to park inside the only parking lot that this institution has. One of the biggest problems is not knowing when a parking lot is free, if they are full or what's the approximate time in line for getting a place to park. Knowing the actual situation, if the potential users of the parking lot could get real time information about the parking lot state, statistics about it or even make a reservation, lots of problems related with it could be solved.
ParkWise is the mobile solution that came out on top of our Impact vs Viability matrix: an information system with occupancy prediction and spot reservation for the parking facilities of Universidad de los Andes and the surrounding area. Instead of driving to campus hoping a spot is free, the driver opens the app and sees, in real time, how many spaces are available on each level, gets a prediction of how full the lot will be at their arrival time, and is guided to the nearest free spot.
The core idea is to remove the uncertainty that turns a five‑minute arrival into a twenty‑minute problem. Every screen is built around one question the user has every morning: "where can I park right now, and how do I get there?"
-
Problem: Daily student drivers waste 15 to 30 minutes circling campus lots or waiting in gate queues during morning peak hours without knowing if spots are available, resulting in missed classes and high stress.
-
Alternative: Drivers gamble by traveling directly to campus, rely on unverified student messaging groups (WhatsApp) for manual updates, or search for off-campus lots only after being turned away at the gate.
-
Solution (ParkWise): A predictive occupancy system and short-window spot reservation system that allows drivers to view live and forecasted floor capacity before leaving home, reserve a spot, and navigate straight to an open stall.
-
Problem: Students requiring accessible parking or EV charging stations frequently arrive to find those designated spots occupied, out of service, or blocked by non-eligible vehicles, forcing long walks or uncharged vehicles.
-
Alternative: Physical security guards manually checking windshield tags at entry gates, or drivers physically driving level-by-level to visually inspect individual chargers and accessible stalls.
-
Solution (ParkWise): Real-time smart filters and dedicated status indicators on the interactive floor map, allowing qualified users to locate, verify availability, and reserve EV chargers or accessible spots directly from the app interface.
-
Problem: Student drivers manage parking payments and permits through disconnected channels (cash kiosks, separate permit portals) and often forget to pay, renew, or move their car before a time limit expires, leading to avoidable fines, wasted trips to payment machines, and last-minute stress. They lack any single place to see whether they have paid, when their permit expires, or how much they have spent on parking this semester.
-
Alternative: Drivers pay with cash at kiosks, set personal phone alarms to avoid overstaying, track permit expiry manually in a notes app, pay fines after the fact, or ask a classmate to go check on their car.
-
Solution (ParkWise): Integrated in-app payment and digital permit management with expiry and time-limit reminders, automatic receipts, and a semester spend tracker, letting drivers pay, extend, and monitor their parking costs in one flow. Unlike the current alternatives, it prevents fines proactively instead of just recording them after they happen, replacing scattered cash payments, manual alarms, and notes with a single dependable channel.
-
Problem: After parking in a large multi-floor structure, students frequently forget the exact level or section and waste 5 to 10 minutes searching for their car when returning, a problem that worsens at night or when they are already running late, adding stress and personal-safety concerns when walking alone through poorly lit areas.
-
Alternative: Drivers try to memorize the level sign or take a photo of it, drop a manual pin in a generic maps app, or walk floor by floor to visually locate their vehicle, often through dimly lit sections.
-
Solution (ParkWise): Automatic capture of the parked stall (level and section) at check-in, in-app wayfinding back to the vehicle, and indicators for well-lit or monitored routes, so drivers relocate their car quickly and return safely. Beyond what any current workaround offers, it removes the need to memorize signs or search level by level and adds a safety dimension that none of the existing alternatives address.
-
Problem: Students who arrive after the campus lot fills up end up parking on surrounding streets or in unverified private lots, where they face break-in risk, unpredictable rates that change without notice, and a walk of several blocks that becomes a personal-safety concern after evening classes. They only discover the lot is full after already committing to the trip.
-
Alternative: Drivers circle the surrounding blocks looking for a street space, ask a classmate which nearby lot is cheapest, or accept whatever rate the first attendant quotes them because they are already late.
-
Solution (ParkWise): When campus occupancy is predicted to be full for the user's arrival window, the app surfaces a ranked list of verified nearby lots with their current rate, remaining capacity and walking time to the destination building. The decision moves from the street to the phone, before the driver leaves home, which is something no current alternative offers.
-
Problem: Drivers who reach the entrance join a queue with no information about what is behind it. They cannot tell whether the line is moving because spaces are opening up or because the lot is full and the guard is turning people away, so they wait an average of 10 minutes only to discover there was never a spot for them.
-
Alternative: Drivers stay in line and hope, watch how many cars exit ahead of them, or give up after an arbitrary amount of time and leave to look elsewhere, losing both the wait and the position.
-
Solution (ParkWise): A live queue indicator that pairs the number of vehicles waiting with the current free capacity and the observed exit rate, so the driver knows before entering the line whether waiting is worth it. Unlike simply seeing a full or empty status, this tells the driver how the situation is trending.
-
Problem: Occupancy information loses accuracy within minutes because drivers register their arrival but never register leaving. A spot that freed up at 10:15 still shows as occupied at 11:00, so the app under-reports availability and users stop trusting it, which in turn reduces the check-ins that feed the data in the first place.
-
Alternative: There is no alternative. The information simply ages, and users fall back on driving over to look for themselves, which is the behaviour the whole solution exists to eliminate.
-
Solution (ParkWise): Automatic exit detection through geofencing, so leaving the campus perimeter releases the spot without any action from the driver. The data stays current through a mechanism that requires no user effort, breaking the cycle where stale data destroys the trust that sustains the data.
-
Problem: Students who drive to campus only once or twice a week have no mental model of when the lot fills or which level empties first. Regular drivers learn these patterns over months of trial and error, but occasional drivers repeat the same mistakes every visit and consistently arrive at the worst possible moment.
-
Alternative: Occasional drivers copy the habits of a friend who drives daily, arrive much earlier than necessary to be safe, or accept that parking will be difficult and budget an extra half hour for every visit.
-
Solution (ParkWise): Historical occupancy patterns presented by day and time slot, so a first-time or infrequent user starts with the same knowledge a daily driver took a semester to acquire. The feature transfers accumulated collective experience to the user who has none.
-
Problem: A reservation system that holds spots creates a new failure mode: users who reserve and never arrive keep a scarce space blocked while other drivers are turned away at the gate. In a lot where capacity is the binding constraint, a small share of no-shows removes a meaningful number of usable spaces during exactly the peak window when they matter most.
-
Alternative: Not applicable, since no reservation system currently exists. The equivalent behaviour today is a driver asking a friend already on campus to hold a spot physically, which fails for the same reason and creates conflict at the gate.
-
Solution (ParkWise): Short reservation windows calibrated to each user's observed travel time, automatic release when the window expires, and a reliability record that shortens the window for users who repeatedly fail to arrive. The system protects scarce capacity rather than assuming good faith.
-
Problem: Deciding when to leave home requires combining three things the driver cannot see together: how long the drive will take, how full the lot will be on arrival, and what time the first class actually starts. Drivers estimate all three from memory, so they either leave far too early and waste time on campus, or leave on time and arrive to find no space.
-
Alternative: Drivers set a fixed departure time that worked once and keep using it regardless of the day, check traffic in a maps app without any parking information, or ask in the semester group chat whether the lot is full right now.
-
Solution (ParkWise): A departure recommendation that combines the occupancy prediction for the arrival window with the travel time and the user's first commitment of the day, delivered as a notification before the user needs to leave. It answers the actual question, which is when to leave, rather than the partial one of whether there is space right now.
-
Problem: Levels P2 and P3 are underground and have neither cellular signal nor GPS reception. This is precisely where the driver needs the floor map, the route to an assigned spot and the record of where the car was left, so a solution that depends on connectivity stops working at the exact moment it is supposed to deliver its value.
-
Alternative: Drivers memorize the level sign, photograph it, or navigate the underground levels visually, which is the behaviour the app was built to replace.
-
Solution (ParkWise): Local caching of the floor plan and the parked-spot record, a queue of pending events that synchronises when signal returns, and a clear offline indicator so the user knows which information is live and which is the last known state. The app degrades honestly instead of failing silently.
-
Problem: The staff responsible for the campus parking facilities can only see the entry counts recorded at the gates. They have no way to know how many people decided not to come, how many ended up parking on the street, or whether the accessible and electric-charging spots are sufficient for the people who need them. Decisions about allocating capacity are therefore made without evidence and are difficult to justify when questioned.
-
Alternative: Monthly spreadsheets assembled by hand from gate counts, occasional manual observation during peak hours, and complaints received after the fact, none of which capture the demand that never reached the gate.
-
Solution (ParkWise): Aggregated reporting of unmet demand by time slot and origin zone, together with effective availability of accessible and charging spots, delivered as a periodic report rather than through the mobile app. It measures the demand that current instrumentation cannot see, which is the part that matters for allocation decisions.
-
Map Load Performance and Failure Rate: What is the loading time of the interactive floor map and the rate of failed loads, broken down by device model, OS version and parking level (P1, P2, P3)? Data source: app telemetry and error logs. The breakdown by level matters because P2 and P3 are underground and have no signal, so a map that depends on the network fails exactly where the driver needs it.
-
Reservation Flow Latency and Crashes: What is the response time of the reservation confirmation and the crash/ANR rate along the reservation flow, broken down by device model and OS version? Data source: app telemetry and error logs. Reservation happens under time pressure at the gate, so a slow or crashing confirmation directly makes the driver lose the spot they were promised.
-
Predicted Occupancy by Level: What is the predicted occupancy of each level (P1, P2, P3) in 15-minute time slots for the arrival time the user indicates? Data source: historical check-ins and fulfilled reservations, aggregated by level and slot. Displayed as the main card on the home screen, before the user leaves home.
-
Walking Time per Spot: What is the walking time from each available spot to the entrance of the user's destination building? Data source: parking floor plan with spot and entrance coordinates, combined with the destination declared by the user. Displayed as a minutes label on each spot card in the search view.
-
Specialized Spot Availability: What proportion of the time is at least one accessible spot and at least one charging spot free, by time slot and by level? Data source: per-spot occupancy state cross-referenced with spot type from the floor plan. Displayed as an availability indicator inside the accessibility and Electric filters, so the user decides whether to come at all.
-
Personal Reservation Lead Time: How far in advance should this specific user reserve for the reservation to still be valid on arrival, based on their own history of travel times? Data source: personal history of reservations created, fulfilled and expired, cross-referenced with observed travel times. Displayed as a suggested reservation moment on the reservation screen.
-
Reservation Conversion Gap: Among users who check live availability, what percentage completes a reservation, and at which step of the flow does the rest drop off? Data source: navigation events across the reservation funnel. Supports the decision of whether to reduce steps in the flow or relocate it in the interface.
-
Filter Usage Distribution: How many times per month does an active user apply each filter (Available, VIP, Electric, accessible), and what percentage of users has never used one of them? Data source: filter application events per user. Supports the decision of whether to keep the four filters or consolidate them, since a filter nobody touches occupies screen space and code that must be maintained.
-
Voice Versus Text Search: What proportion of searches is performed by voice rather than text, and which modality has the higher rate of a result being selected? Data source: search events tagged with modality and outcome. Supports the decision of whether voice search should be kept, improved or removed, since engine noise in an underground level makes the assumption that voice performs better a hypothesis to verify rather than to assume.
-
Prediction Versus Live-Only Usage: What proportion of sessions rely on the occupancy prediction (checked before leaving home) versus only the live map on arrival, and does predicting change whether the user ends up finding a spot? Data source: session events tagged with prediction view and outcome. Supports the decision of whether to invest further in the forecasting feature or simplify it, since a prediction users ignore is model cost that must be maintained without payoff.
-
Unmet Demand by Time Slot and Zone: What is the volume of availability queries in which no campus spot was available, segmented by time slot and by the user's origin zone? Data source: availability queries with no positive result, with timestamp and geographic origin. This is quantified unmet demand that no parking operator in the area currently has. It supports negotiating preferential rates with the verified nearby lots the solution already contemplates, and gives the university numerical evidence to justify additional capacity or alternative transport incentives. The insight is delivered aggregated by zone and slot, never at the individual user level, and sharing it with a third party requires explicit consent in the terms and conditions.
-
Off-Campus Redirect Value: When campus is full, what share of redirected drivers actually parks in a suggested nearby lot, and what is the resulting volume by lot and time slot? Data source: redirect events cross-referenced with subsequent check-ins at partner lots (where integrated) or user-confirmed arrivals. This quantifies the traffic ParkWise sends to each partner lot, giving a basis to negotiate referral agreements or preferential rates. The figure is delivered aggregated by lot and slot, never at the individual level, and sharing it with a partner requires explicit consent in the terms and conditions.
-
Reported Versus Verified Occupancy: What is the deviation between the occupancy ParkWise reports and the real occupancy verified at the gates, by level and time slot? Data source: system occupancy state compared against the official gate counts, which we do not yet have. This question is mixed because it is type 1 in that it measures the quality of the data collection mechanism, type 3 in that it decides whether an official source must be integrated or the spots instrumented, and type 2 in that the confidence indicator shown next to every prediction is derived from it. It supports the decision of whether to pursue an agreement with the university for access to the official count, and with what margin of error the prediction is communicated to the user.
-
Reservation Policy Optimization: Given predicted occupancy and this segment's historical no-show and overstay rates, what reservation-window length and how many held spots per level maximize fulfilled reservations without turning away drivers who arrive on time? Data source: prediction outputs combined with reservation history (created, fulfilled, expired) by level and segment. This question is mixed: type 4 because it turns behavioral data into a policy decision, type 2 because the recommended reservation window is shown to the user, and type 3 because a poor result may mean redesigning or removing open-ended reservations. It supports setting the reservation rules that balance guaranteed spots against lot utilization.
