Final Submission

1. Problem, Solution, Revenue Model & Value Proposition

1.1 Problem Description

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.

1.2 Solution Description

What ParkWise is

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?"

1.3 Revenue Model

ParkWise combines a freemium consumer model with a B2B data service, plus two transaction based streams. The consumer subscription and the university data service are the primary drivers; the other two scale with usage.

• Freemium subscription (B2C — primary). The free tier shows real time availability and the basic floor map. The premium tier (monthly or per semester) unlocks the features that remove the real uncertainty: occupancy prediction, spot reservation, departure recommendations, wayfinding back to the car, and the semester spend tracker. Most revenue comes from daily drivers who value not losing 20 minutes every morning.

• Reservation & payment transaction fees. A small fee is charged on each reservation and on each inapp payment or parking extension processed through ParkWise. This ties revenue directly to the moments where the app saves the driver a fine or a wasted trip.

• University / operator analytics (B2B). The aggregated reporting from PAS 12 unmet demand by time slot and origin zone, effective availability of accessible and EV spots is sold to the university's parking administration as a periodic data subscription. It gives them evidence for capacity decisions they currently make blind, and it's data no operator in the area has today.

• Partner lot referral commission. When campus is predicted full, the app redirects drivers to verified nearby lots. ParkWise earns a referral fee or commission per driver who actually parks at a partner lot, turning the off campus overflow problem (PAS 5) into a revenue stream while helping the user.

1.4 Value Proposition

ParkWise offers students and users of Universidad de los Andes parking facilities a faster, more informed, and reliable way to find and manage parking spaces. The app combines real time availability data, occupancy forecasting, space reservation, and navigation to available spots, allowing users to stay informed about parking conditions both before and during their arrival.

In this way, ParkWise aims to reduce uncertainty, time wasted in lines, and the difficulty of finding a spot, providing a more convenient and predictable parking experience. It also addresses specific needs, such as locating spaces for electric vehicles or individuals with reduced mobility.

2. Problems, Alternatives & Solutions (PAS)

PAS 1: Morning Commute Uncertainty & Traffic Congestion

• 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.

PAS 2: Inaccessible & Unpredictable Specialized Parking (EV & Reduced Mobility)

• 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.

PAS 3: Payment Friction & Permit Management

• 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.

PAS 4: Vehicle Relocation & Safe Return in Multi-Level Structures

• 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.

PAS 5: Off-Campus Overflow Parking

• 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.

PAS 6: Blind Gate Queue

• 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.

PAS 7: Stale Availability From Unregistered Exits

• 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.

PAS 8: Unfamiliarity With Lot Dynamics

• 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.

PAS 9: Reservation No-Shows

• 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.

PAS 10: Departure Planning Disconnected From the Schedule

• 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.

PAS 11: The App Fails Where It Is Most Needed

• 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.

PAS 12: No Evidence Base for Capacity Decisions

• 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.

3. Context Canvas

4. Personas

4.1 Prospective Personas

(Persona 1)

(Persona 2)

(Persona 3)

4.2 Analytics Persona

5. Empathy Maps

(Empathy Map 1)

(Empathy Map 2)

(Empathy Map 3)

(Empathy Map 4)

6. Business Questions

Type 1.

• 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.

Type 2.

• 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.

Type 3.

• 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.

Type 4.

• 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.

Type *.

• ⁠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.

7. VD Map

8. Functional Scenarios

• While at home and planning their commute an hour before departure, the user selects a predicted free spot and requests a reservation, prompting the system to validate availability, lock the spot temporarily, and issue a digital reservation ticket.

• Upon arriving at the parking lot entrance, the user opens the interactive floor map to check current occupancy, allowing the system to fetch real-time data from sensors and check-ins to highlight available spots.

• To find the most convenient place to park, the user enters their destination building into the search bar, enabling the system to calculate and sort the shortest walking paths from available spots to the building.

• Thirty minutes before their typical departure time, the user receives a push notification from the system warning them that the lot is expected to be full by their usual arrival time.

• While in class and receiving a time-limit warning, the user pays for a parking extension via the app to avoid penalties, which allows the system to process the payment, update the digital permit, and send a confirmation receipt.

• As an EV owner needing a charge during their stay, the user requests a specific charging spot, prompting the system to filter for EV-enabled spaces, verify real-time availability, and facilitate the reservation.

• Upon reaching the parking lot gate, the user triggers the 'Check-in' action so the system can assign the reserved spot, provide the exact floor and section, and mark the spot as occupied.

• After finishing their activity and returning to the parking lot, the user requests wayfinding back to their vehicle, allowing the system to retrieve the stored check-in location and provide a guided path from their current position.

• To avoid crowds when planning tomorrow's trip, the user views historical occupancy patterns via a chart of peak hours and typical vacancies per level for that specific day of the week.

• While physically at a spot and noticing it is empty, the user reports it as 'stale', which triggers the system to re-verify the spot's status and update it to 'Free' for other users.

• To ensure a smooth arrival on campus, a user with limited mobility reserves an accessible parking spot, which the system grants after verifying the user's digital permit for reduced mobility.

• While stuck in traffic and arriving late, the user receives a notification that their reservation window is expiring, warning them they have five minutes to arrive before the system releases the spot to other drivers.

9. Quality Scenarios

• While parked in P2 without a signal, the user opens the floor map, and the system instantly displays the last cached map with an 'Offline' indicator in under one second.

• When two users attempt to reserve the same spot at the exact same millisecond, the booking database ensures zero overbooking by granting the spot to only one user and immediately notifying the other.

• Upon arriving at the lot at the predicted time, the user verifies the available spots, which match the occupancy engine's prediction within a 10% margin of error.

• Immediately after installing the app, a new user attempts to make their first reservation, successfully completing the entire reservation flow independently in under two minutes to ensure efficient onboarding.

• During peak network traffic, the user submits a payment for a parking extension, and the payment gateway ensures the transaction is processed exactly once to prevent double charging.

• If the app crashes while the user is in the middle of a reservation, the system restores the session state upon restart, returning the user to the last step with zero loss of input data.

• To get an instant update on availability, the user clicks 'Refresh' on the occupancy map, and the system updates all spot statuses and re-renders the map in under two seconds.

• As a user drives away and leaves the campus perimeter, the geofencing service automatically marks the spot as free and releases the reservation within 30 seconds of the exit.

• When an unauthenticated user attempts to check in using another driver's active reservation, the system denies the action, requires valid credentials, and keeps the permit's personal data encrypted, blocking 100% of access attempts made without valid credentials.

• During the 7–9 AM peak, when 500 users query availability and submit reservations concurrently, the system serves all requests without downtime and responds to 95% of availability queries in under two seconds.

• When a user tries to reserve a spot that was just taken by someone else, the system shows a clear message explaining what happened and suggests the nearest available spot in under two seconds, so the user is never left confused about why the reservation failed.

• When a new parking level or lot is added to the campus, a developer can register it in the system and have it appear on the interactive map without changing the core code, completing the update in under one day of work.

10. Ethics Video

CLICK HERE TO GO TO THE ETHICS VIDEO