Unlocking Mentee Engagement: Shifting from Auto-Reprobation to Transparent Communication

Introduction

In the landing project, we manage various community initiatives, including a mentorship program designed to connect mentees with experienced mentors. A core challenge in such programs is managing attendance and ensuring engagement. Our initial approach to handling mentee absences involved an automated 'reprobation' flow, intended to streamline the process for non-attending mentees. However, as we scaled, this automated system began to create more problems than it solved.

The Problem: Hidden Consequences of Automation

Our previous system automatically marked mentees as 'reprobated' and silently locked them out of their mentorship slots after two consecutive absences. This was managed internally through columns like mentor_subscriptions.reprobated_at and mentor_bookings.absence_warning_sent_at.

The intention was to free up slots for active mentees, but the reality was far from ideal:

• Silent Lockouts: Mentees were locked out without explicit communication, leading to confusion and frustration when their access disappeared.
• Support Pain: Mentors attempting to re-enroll a mentee found that previously booked slots remained unavailable, leading to a complex support interaction to manually untangle the 'reprobated' status.
• Lack of Control: Neither the mentee nor the mentor had a clear path to resolve the situation, forcing them to engage with support for what felt like an arbitrary system decision.

This opaque automation was a source of significant support overhead and a poor user experience, undermining the very engagement the program sought to foster.

The Solution: Empowering Users with Clear Information

To address these issues, we refactored our mentorship absence handling by completely removing the auto-reprobation logic. The new approach prioritizes transparency and communication, empowering both mentees and mentors.

The key changes involved:

1. Removing Reprobation Logic: The automatic reprobation mechanism, including the reprobated_at and absence_warning_sent_at columns, has been dropped from the database schema and the application logic.
2. Informational Email Notifications: Instead of a silent lockout, now after each absence, an informational email is sent to both the mentee and their mentor. This email clearly communicates the absence and, crucially, advises the mentee to contact their mentor directly if they wish to stop attending.
3. Data Migration: A one-time migration was executed to restore all future bookings that had been previously cancelled due to the old reprobation system, ensuring no active mentees lost their rightful slots.
4. Simplified Reactivation: The mentor reactivation process is now straightforward, as there's no 'reprobated' status to contend with.
5. Localized Messaging: All absence warning messages are now localized across English, German, Spanish, and French, enhancing clarity for our diverse user base.

Conceptually, the change moved from an implicit system decision to an explicit communication flow. Here's a simplified illustration of the shift:

// Old conceptual approach (simplified)
class MentorshipAbsenceHandler {
    public function processAbsence(Mentee $mentee, Booking $booking): void {
        // ... logic to check consecutive absences ...
        if ($mentee->hasConsecutiveAbsences() && !$mentee->isReprobated()) {
            $mentee->markAsReprobated(); // Sets reprobated_at
            $mentee->cancelFutureBookings();
            // Silent lockout, no explicit notification
        }
    }
}

// New conceptual approach (simplified)
class MentorshipAbsenceHandler {
    public function processAbsence(Mentee $mentee, Booking $booking): void {
        // Record absence, but no auto-reprobation
        $mentee->logAbsence($booking);

        // Send clear notifications to all parties
        Mail::to($mentee->getEmail())->send(new MenteeAbsenceWarning($mentee, $booking));
        Mail::to($booking->getMentor()->getEmail())->send(new MentorAbsenceNotification($mentee, $booking));

        // Mentees remain active unless they or mentor decide otherwise
        // Future bookings now remain intact
    }
}

Immediate Benefits & Future Considerations

The immediate impact of this refactor is a significant reduction in support requests related to mentee lockouts. Mentors now have a clearer view of their mentees' status, and mentees are no longer surprised by missing bookings. The system is more predictable and user-friendly, fostering better engagement within the mentorship program.

This shift also cleans up our data model by removing unused columns, making the system easier to maintain and understand. We anticipate improved retention as mentees feel more in control of their participation.

Designing for Transparency

This refactor highlights a crucial lesson in product development: always favor transparency and user control over silent, automated decisions. While automation can improve efficiency, it should never come at the cost of user experience or clarity. When a system makes a decision that impacts a user, that decision and its implications must be communicated clearly and directly.

Key Insight

If an automated process leads to user confusion or frequent support interventions, it's a strong signal to re-evaluate its design. Empowering users with timely, explicit information, and giving them avenues for action, often leads to a more robust and satisfying experience than any hidden automation ever could.