🧩 Designing the Slot System That Powered 1:1 Mentorship on Mentorpedia

A case study on how we structured real-time availability and session control

TL;DR

The Slot System was the backbone of Mentorpedia’s booking engine. It allowed mentors to set their availability and students to schedule sessions with clarity and trust. I designed this system to reduce friction, prevent double bookings, and ensure both sides felt in control — without adding unnecessary complexity.

🎯 What We Needed the Slot System to Do

• Let mentors easily set availability (without needing technical know-how)

• Display open time slots in student time zones, in real-time

• Prevent overlaps, double bookings, or missed sessions

• Integrate with a credit-based wallet system and Google Meet auto-link generator

• Make it feel intuitive on mobile and desktop

📐 How the Slot System Worked

For Mentors:

• Mentors chose available days & time windows (e.g. Mon-Fri, 6–9 PM)

• Time slots auto-generated in 30 or 45 min blocks

• Slot expiry logic: disabled if session was <3 hours away

• Could pause all slots with 1 toggle (for breaks or holidays)

For Students:

• Saw mentor slots based on their local time zone

• Slot colors indicated status:

  • ✅ Green: Available

  • ⛔️ Red: Booked

  • 🕓 Grey: Expired or Past

• Could only book one active session per mentor at a time

⏱ Real-Time Logic

• Built using Firebase Firestore with slot document objects per mentor per day

• Booking writes a “locked” flag to slot object → triggers Firestore rule to prevent overwrite

• Backend function checks if wallet credits are available before allowing booking

• Sessions stored with timestamp + status (Pending / Confirmed / Completed)

📲 UX Considerations

• Mobile-first layout with swipeable calendar

• Next 7 days shown — no overwhelming monthly view

• Mentors could preview how students saw their slots (reduced confusion)

• Sessions only shown 12 to 72 hours in advance (no long-term planning overload)

🔁 Edge Case Handling

• Booking window closed 3 hours before the slot (to prevent last-minute chaos)

• Double-book prevention with atomic Firestore transaction

• Cancelled slots were reopened in the system automatically

• No-shows flagged in mentor dashboard with option to “block slot reuse”

🔧 Tools Used

• Figma for interaction mapping & UI

• Firebase Firestore + Cloud Functions for real-time slot management

• Google Meet API for calendar + link creation

• Timezone management via Luxon.js

📈 What This Solved

Before SlotsAfter SlotsStudents unsure when mentors were available100% visibility with daily color-coded slotsLast-minute cancellations disrupted planningBuffer time + auto-expiry added reliabilityDouble bookings in early MVPResolved via atomic locking logicMentors manually managing availability1-time setup with ongoing automation

💡 What I Learned

• Time UX is emotional — people want control, clarity, and commitment

• Real-time booking is not just about tech — it’s about respecting everyone’s time

• A good slot system reduces back-and-forth, increases trust, and creates rhythm in the platform

• Even subtle changes — like adding a 3-hour buffer — radically improved experience

🔮 Future Enhancements (if we continued)

• Google Calendar sync for mentor availability

• AI-based smart slot suggestions (“students like you booked Tuesdays”)

• Auto-reminders based on slot patterns (if you book 2 Mondays, suggest the third)

• Group slot bookings or cohort-style sessions

Final Thoughts

The slot system in Mentorpedia wasn’t flashy — but it was powerful. It quietly handled what most platforms struggle with: respecting time, building trust, and making mentorship feel organized. This project helped me understand how simple systems, when well-designed, can drive serious impact.

Want to see the slot system flow in action?
→ Explore at amishsri.framer.website