# PairingPal App Overview ## What PairingPal actually is At a high level, PairingPal is a **crew-life planning and bid-intelligence app** for flight attendants. It sits between: - the airline/crew-planning ecosystem - the monthly bid package - the bidding system - the final awarded schedule - the flight attendant’s real life calendar The bid package already contains schedule constraints, reserve allocations, pairings, training, special statuses, and deadlines, and crews must submit bids through NavBlue by a monthly deadline, then review draft/final schedules in a defined protest window. So the app is not “just a parser.” It is a **monthly operating assistant**. --- ## The real app in one line **Input ugly airline planning documents → normalize the month → help the user decide/bid/track → turn outcome into a usable life-planning calendar.** --- ## Core user workflows ### 1) Monthly package intake **User goal:** “I just got the new monthly bid package. Tell me what matters.” **Input:** - monthly bid package PDF - pairings package PDF - reserve package PDF - flying lines - reserve lines - guide/reference documents The December 2024 bid package example includes bidding deadlines, protest timelines, reserve definitions, reserve line counts, training references, and monthly base information. **App output:** - bid month - base - bid deadline - draft review/protest window - final award timing - reserve rules and reserve counts - flying line counts - training notices - special notes (deadheads, bilingual pairings, stat-day offerings, blocking window, reduced block/off-schedule notes) **Why this matters:** This becomes the **month context** for everything else. ### 2) Pairing and line extraction **User goal:** “Show me the actual flying/reserve choices in a usable way.” **Input:** pairings pages, line pages, and reserve pages from the monthly package. The NavBlue guide makes clear that users bid either for a **pairing/flying schedule** or for **reserve**, and these are separate bid-group concepts. **App output:** - pairings - reserve blocks - days off - training - vacation / GDO extensions / reduced block / off schedule - carry-in / carry-out impacts - check-in and check-out times - destinations / landings / deadheads - duty length / legs / multi-day structure The bidding guide also shows pairings can be filtered by duty legs, enroute check-in/out, pairing check-in/out, landing stations, and preference order. **Why this matters:** Without normalized pairings, the app cannot become intelligent later. ### 3) Rules and legality context **User goal:** “Help me without suggesting something that breaks bid logic, reserve logic, or contract rules.” **Input:** - collective agreement - bid guide - reserve rules - planning rules in the monthly package Collective agreement excerpts show reserve assignment behavior, required check-ins with Crew Scheduling, reserve reassignment logic, multi-day coverage logic, and monthly bid publishing/closing/award dates. The NavBlue guide shows bid mechanics like reserve bid groups, default bids, preferred days off, patterns, consecutive days off, max-above reserve behavior, and waivers involving days off between reserve stretches, pairing-to-reserve, and training. **App output (flags):** - bid deadlines - protest deadlines - reserve/flying distinctions - DOR-style constraints - pattern and day-off implications - waiver-dependent outcomes - cases where a user may have been forced to reserve because a legal block could not be built **Why this matters:** This is the difference between a document viewer and a decision-support app. ### 4) Bid planning workflow **User goal:** “Help me plan what to bid before I submit NavBlue.” **Current real-world process:** Users read the package, then manually build bid preferences in NavBlue. Preferences are ranked in order, use different bid groups for pairing vs reserve, and require an up-to-date default bid. **App output should let the user define:** - preferred days off - desired reserve vs flying preference - consecutive days off - vacation extensions/GDOs - max duty-day preferences - landings to avoid or prefer - check-in / check-out time preferences - weekend/holiday targets - minimum buffer days before/after reserve or training - preferred credit window targets - backup/default bid strategy **What the app does:** - generates a clean summary of bid strategy - recommends order of preferences - explains “why you might get reserve” - provides a checklist before submission - optionally produces copyable notes/screenshots/helper text for NavBlue entry **Why this matters:** The app adds value **before the award happens**. ### 5) Awarded schedule interpretation **User goal:** “My schedule has been awarded. Explain my month clearly.” The bid package describes a short draft review/protest period, and the NavBlue guide says users must use the protest process for errors and cannot change bids after closure. **App output:** - monthly calendar - working days - reserve days - days off - layovers - training - carry-ins/carry-outs - warnings about tight transitions - explanation of why the award may have happened The NavBlue guide mentions why someone might get reserve while a junior person gets a flying line (credit window, vacation/training conflicts, DORs, part-time windows, carry-in credit, waivers). **Why this matters:** This is where users switch from “bid system language” to “my life next month.” ### 6) Calendar and life-planning workflow **User goal:** “I want my month turned into something I can actually use.” **App output:** - calendar export - spouse/family-safe calendar view - work vs off vs reserve color-coding - trip blocks - long weekends - vacation attachments - reminders - printable summary - conflict/overlap detection **Later extensions:** - Google/Apple/Outlook sync - hotel/commute planning - childcare planning - side-job planning - budgeting around block type and expected credits **Why this matters:** Users don’t buy “PDF extraction.” They buy **clarity and usable time**. ### 7) Protest / exception workflow **User goal:** “I think my draft/final schedule is wrong. Help me identify whether there’s a protest-worthy issue.” The package and NavBlue guide both describe a limited review/protest period after draft posting, and protests are for possible errors, not bid changes. **App output:** - schedule anomaly detection - missing training checks - conflicting duties - incorrect days off - suspicious reserve assignment patterns - timeline reminder: protest window closes soon - contact info / protest checklist **Why this matters:** High trust, high sensitivity; checklist support is still highly valuable. ### 8) Historical learning workflow **User goal:** “Help me bid smarter each month based on what happened before.” **App output over time:** - prior month bids vs awarded result - reserve frequency by month/base - preference success rate - common reasons for misses - preferred day-off hit rate - line quality trends - reserve-to-flying patterns - waiver impacts on outcomes **Why this matters:** Evolves from monthly helper to personal bidding intelligence engine. --- ## What data the app really needs (business data) ### A) User profile - employee/base - seniority band (if relevant) - language qualification - preferences - reserve tolerance - family/life constraints - recurring must-have days off - part-time / reduced block / special status indicators ### B) Month package - month - base - deadlines - reserve planning notes - block window - line counts - training notes - special monthly notices ### C) Pairings and schedule objects - pairing code - date span - check-in / check-out - destinations - legs - layovers - deadhead flags - bilingual flags - reserve type / reserve days - training/vacation markers ### D) Bid preferences - preferred off dates - reserve vs flying intent - pattern rules - max/min days off - landing preferences - timing rules - reserve constraints - waiver choices - default bid template ### E) Award result - awarded pairings - reserve days - days off - credit range - conflicts - reasons/explanations - protest flags --- ## Product modules (app-first view) 1. **Inbox / Imports** — upload bid package PDFs, pairings package, reserve lines, final schedule files. 2. **Month Dashboard** — deadlines, key notes, flying vs reserve counts, training/special notices, month-over-month changes. 3. **Pairings Explorer** — pairings, filters, reserve lines, day-off patterns, trip characteristics. 4. **Bid Planner** — define goals, rank preferences, test likely outcomes, build recommended bid plan. 5. **Awarded Schedule** — full month calendar, pairing/reserve/off/training display, explanations, draft vs final comparison. 6. **Calendar Sync / Export** — move work month into life tools. 7. **Alerts / Issues** — deadline reminders, protest windows, blocking errors, missing days off, unusual assignments. 8. **History / Insights** — monthly learning and decision improvement. --- ## Real app workflow from month start to month end ### Workflow 1 — Package drops 1. User uploads package. 2. App extracts month facts. 3. App shows summary. 4. App flags deadlines and action items. ### Workflow 2 — User prepares bid 1. User states goals. 2. App interprets pairings/reserve options. 3. App suggests structured bid strategy. 4. User enters bid in NavBlue. ### Workflow 3 — Draft award posts 1. User uploads/enters draft award. 2. App converts to readable schedule. 3. App flags anomalies. 4. App provides protest checklist. ### Workflow 4 — Final schedule posts 1. App locks final month view. 2. App exports calendar. 3. App supports reserve/day-off planning. 4. App tracks history for future learning. --- ## What users are actually buying Not a parser, terminology helper, or another document viewer. Users are buying: - less confusion - less manual reading - better bidding confidence - easier schedule interpretation - faster conversion from “crew system” to “my life” --- ## MVP vs later ### MVP - upload monthly PDFs - extract deadlines and month context - extract pairings/reserve/off/training into usable structure - show month calendar - allow manual tagging/fixing when parser misses - export to calendar - basic bid-planning notes/checklists ### Phase 2 - stronger rule engine - protest/error assistant - bid strategy builder - historical comparisons ### Phase 3 - predictive bid intelligence - base/seniority analytics - smarter reserve-likelihood explanation - family/shared planning tools --- ## Clean app summary PairingPal is a **monthly planning operating system for flight attendants**. It does four things: 1. **ingests** bid-package data 2. **interprets** pairings, reserve, deadlines, and rules 3. **guides** bid and review process 4. **translates** awarded month into life-planning tools Main workflows: - import month - understand pairings - plan bid - review award - export calendar - learn from prior months --- ## Most important product decision Decide if v1 is primarily: A. Schedule interpretation app — “Upload your month, get a clean calendar.” B. Bid strategy assistant — “Plan better bids before submission.” C. Full monthly operating assistant — “From package to award to calendar.” **Recommendation:** Lead with **C in narrative**, but build **A first**. Ship first: - import - interpret - calendarize - deadline alerts That is the most realistic wedge.