Why Universities
Are Broken.
Students at most universities operate across 8–12 disconnected systems — a separate portal for registrar, another for dining, a third for library, different apps for transport and health. No single system understands intent. No system can answer "what do I do next?"
Admin teams receive the same questions hundreds of times per week. Tier-1 support is dominated by queries like "where do I drop a course?" and "how do I request a transcript?" — tasks a well-designed AI system could handle in seconds.
Core Insight
The problem isn't missing information — it's missing intelligence. Every answer exists somewhere on the university website. The gap is that students can't find it when they need it, in the way they think about it.
Users & Pain Points
- Students: Navigate fragmented systems; can't find answers across silos; high cognitive load during critical decisions (registration, graduation, aid)
- Admin Teams: Overwhelmed by repetitive tier-1 queries; no visibility into what students are struggling with at scale
- Service Departments: Data exists in isolation; no unified way to surface it contextually
- University Leadership: No product-level intelligence on student friction points; decisions made from lagging indicators
How I Approached
This Problem.
Customer Wedge
Don't boil the ocean. The entry wedge is first-year student orientation — the highest-anxiety, highest-friction moment in the university lifecycle. Students need to navigate housing, registration, dining, ID, email, and financial aid simultaneously. Nailing this moment builds trust and stickiness for four years.
Personas
- The Overwhelmed Freshman (Sam): First-gen student, 18, never used a university portal before. Primary goal: not fall behind. Won't read FAQs. Will talk to a chat interface at 11pm.
- The Power User (Jamie): Senior, double major, knows the system. Uses the tool for edge cases: petitions, appeals, unofficial transcript timelines, research lab applications.
- The Admin Coordinator (Dr. Chen): Processes 60+ student requests/week manually. Wants escalation clarity — know when to step in, have AI handle the rest.
Prioritization Framework
Applied RICE scoring across 18 proposed features. Top three by RICE: (1) Registrar Q&A — highest reach, daily frequency; (2) AI Copilot — highest impact, core product belief; (3) Admin Dashboard — unlocks institutional adoption. Deferred: gamification, social features, calendar sync (high effort, low retention evidence).
MVP Scope Decision
What's In MVP
Student command center with RAG copilot · Registrar + library + dining + transport Q&A · Citation-based answers with confidence thresholds · Admin escalation queue · Single-department pilot (Registrar). What's NOT in MVP: multi-institution support, mobile native app, real-time inventory.
Metrics & KPIs
40%
Tier-1 Deflection Target
- North Star: Student sessions ending with "I got my answer" (self-reported or inferred via no-escalation)
- Engagement: WAU, queries per session, repeat usage by cohort
- Quality: Hallucination rate, citation accuracy, escalation precision, time-to-resolve in admin queue
- Trust: NPS, admin override rate (leading indicator of AI trust), escalation abuse rate
Experiment Backlog (Priority Order)
- A/B: Citation format — footnote-style vs. inline link. Hypothesis: inline improves confidence without slowing reading.
- A/B: Confidence threshold — Surface answer at 70% vs 80% groundedness. Tradeoff: coverage vs accuracy.
- Test: Persona-adaptive tone — Does adjusting formality by student year improve NPS?
- Test: Proactive nudges — Push alerts during registration windows. Hypothesis: reduces deadline-driven surge queries.
Risks & Tradeoffs
- Hallucination risk: Mitigation — citation-only answers, hard fallback to escalation at <70% confidence
- Data freshness: University policies change mid-semester. Mitigation — source TTL tagging, re-ingestion triggers on CMS edits
- Institutional adoption: IT security review, FERPA compliance, SSO integration are pre-GTM gates, not afterthoughts
- Cold-start quality: RAG accuracy is dataset-dependent. Mitigation — curate and validate 200+ QA pairs before launch
RAG Architecture
& Eval Framework.
Campus Atlas is built on Retrieval-Augmented Generation — not a fine-tuned model, not prompt engineering alone. RAG was chosen because university data changes frequently (policies, deadlines, personnel), and we need traceability to source documents for FERPA-defensible answers.
Campus Atlas · RAG Architecture
Student Query
→
Query Processor
intent + entity extraction
→
Embedding Model
text-embedding-3-small
↓
Vector Store
Pinecone / pgvector
→
Chunk Retriever
top-k=5, MMR reranking
→
Context Builder
citations attached
↓
LLM (GPT-4o)
answer generation
→
Groundedness Check
≥ 0.80 threshold
→
Cited Answer
to student
If confidence < 0.70: route to Human Escalation Queue (admin dashboard)
Evaluation Framework
- Groundedness score: Cross-reference answer against retrieved chunks. Target ≥ 0.80. Computed via LLM-as-judge + cosine similarity.
- Citation accuracy: Does the cited source URL actually contain the claim? Manual spot-check 10% of production answers weekly.
- Hallucination rate: Answers that contain information absent from retrieved context. Target < 3%. Tracked via eval harness on synthetic test set.
- Escalation precision: Are the escalated queries the ones that needed human review? Measure: admin override rate on AI-answered queries.
- Human-in-the-loop: Admin sees escalated query + reason for escalation + relevant source chunks. Can approve, correct, or override. Corrections feed back into eval log.
Data Ingestion Strategy
- Source: University website, course catalog PDF, registrar policy docs, dining menus, campus maps
- Chunking: 512-token chunks with 64-token overlap; section-aware splitting for policy docs
- Metadata: source URL, document type, last-updated timestamp, department, TTL
- Refresh: Nightly re-ingestion for high-churn sources (dining, library hours); policy docs on CMS trigger
From Prototype
to Platform.
| Phase | Timeline | Focus | Success Signal |
| Phase 0 · MVP |
Now |
Registrar Q&A · RAG copilot · Prototype |
100 student beta users · <5% hallucination rate |
| Phase 1 · Pilot |
M1–M3 |
Single department launch · Admin dashboard · Eval harness live |
30% tier-1 deflection · Admin NPS > 40 |
| Phase 2 · Expand |
M4–M6 |
Library + dining + transport · Confidence tuning · Proactive alerts |
5 departments · WAU retention > 60% |
| Phase 3 · Scale |
M7–M12 |
Multi-department · Analytics layer · API for 3rd-party apps |
University-wide contract · 40% deflection · platform NPS 50+ |
GTM Strategy
- Landing customer: Target mid-size universities (5,000–20,000 students) with active digital transformation initiatives. Avoid Tier-1 research universities first (long procurement cycles).
- Champion: VP of Student Affairs or Dean of Students — they own the pain, have budget discretion, and are frustrated by IT-led portals that don't solve student problems.
- Sales motion: Pilot with one department, measure deflection, show ROI in admin hours saved. Expand to university-wide on proven metrics.
- Pricing: Per-institution SaaS, tiered by student enrollment. Freemium single-department pilot. Full contract at university level.
- Launch moment: New student orientation — maximum anxiety, maximum query volume, maximum proof of value.
Impact (Honest Framing)
- Designed end-to-end PM case study with full product lifecycle documentation
- Built working prototype demonstrating RAG copilot with citation-based answers
- Created evaluation framework with groundedness, hallucination, and escalation metrics
- Defined KPIs, launch roadmap, and 4-phase GTM strategy
- Converted a higher-ed pain point into a recruiter-ready AI PM portfolio artifact