I explored how a mentoring platform could move beyond static system emails toward context-aware engagement nudges.
As the sole designer and driver of this exploration, I consolidated 82 scattered email scenarios into four reusable trigger families. I then defined 20 primary intervention contexts across five match types and four participant states, with behavioural signals adapting the final recommendation. The resulting model showed how AI-assisted engagement could scale responsibly through transparent automation while preserving administrative oversight.
Mentoring programs depend on a sequence of participant actions: people need to register, get matched, book their first session, continue meeting, respond to feedback, and complete the program.
When participants slow down or drop off, admins are responsible for getting them back on track. But that work is difficult to scale. Admins need to know what is happening, decide whether an intervention is needed, write the right message, and send it at the right time.
The system supported communication, but it did not give admins enough guidance on when to intervene, what to say, or which participant state mattered most.
The result was a gap between seeing engagement issues and knowing what action to take.
At first glance, this looked like an email template problem.
Admins needed better messages, clearer calls to action, and less manual work. But as I mapped the program lifecycle, the deeper opportunity became clearer: It needed a way to understand participant state and recommend the right intervention.
The core design question became:
How might we help admins send the right nudge, to the right person, at the right moment, while keeping the logic transparent and controllable?
This reframed the work from generating better emails to designing an intervention system.
To understand where participants needed support, I plotted existing system emails and identified email use cases across the full mentorship lifecycle: pre-program, early program, midpoint, program end, and post-program.
I organized the emails by category, including registration, matching, sessions, surveys, content, events, achievements, admin, and system messages.
This made the complexity visible. The problem was not simply that there were many emails. The issue was that different types of communication were being treated the same way.
Some emails were lifecycle reminders. Some were participant interventions. Some were admin broadcasts. Some were recovery moments. Without a clearer model, it was difficult to know which messages should be scheduled, which should be triggered by behavior, and which should adapt based on context.
Engagement gaps were not caused by a lack of emails. They were caused by a lack of intervention logic.
Admins needed a clearer way to understand when a participant needed support, what kind of support was appropriate, and which message strategy would move them forward.
The opportunity was to translate scattered communication use cases into a smaller set of repeatable engagement states.
I normalized both the existing system emails and the additional identified email use cases into four core trigger families:
T1 — No Match Yet
The participant is unmatched, has no requests, opted out, or needs to be recruited back into the matching flow.
T2 — Pre-First Session
The participant has been matched but has not booked or completed the first session.
T3 — Inactivity While Paired
The mentoring relationship exists, but there has been no recent meeting or booking activity.
T4 — Quality Recovery
The relationship may need support because of low feedback, a “needs help” flag, or another quality concern.
This helped separate true engagement states from other communication moments. For example, achievements, event invites, and surveys may still matter, but they do not always create a new participant state. Depending on the scenario, they may function as scheduled sends, contextual signals, or supporting content within a broader trigger.
In this concept, AI was not positioned as a generic writing assistant.
AI was useful here because it could help scale a task admins were already doing manually: interpreting participant context and turning it into timely, supportive communication.
The goal was to reduce admin effort without removing admin control. The system would detect the participant’s situation, select a strategy using transparent rules, draft a short message, and give the admin control to review, edit, test, or override it. This made AI useful in three concrete ways:
To make the system adaptive, I defined a decision model that combined four inputs:
Match type
Different mentoring relationships have different motivational contexts. A coaching relationship may benefit from accountability, while an onboarding buddy relationship may need a warmer, more supportive tone.
Trigger state
The participant’s current state changes what kind of nudge makes sense. Someone who is matched but has not booked a first session needs activation and a clear next step. Someone who is paired but inactive needs re-engagement. Someone with low feedback or a “needs help” flag needs support and recovery.
Behavioural signals
Signals are contextual cues that adjust the message strategy without necessarily creating a new trigger. Examples include a deadline within seven days, a recent milestone, high peer similarity, new-hire status, low engagement, or missing meeting activity.
Use-case context
Some scenarios naturally imply a certain strategy. For example, “registration closing soon” suggests urgency, while “program halfway” suggests accountability.
The decision formula was:
Score = Match type prior + Trigger adjustment + Signal adjustments + Use-case nudge
This made the recommendation logic transparent and tunable. The goal was not to let AI freely decide what to say. The goal was to create transparent decision logic that could explain why a message was recommended.
I used Cialdini’s persuasion principles as the behavioral framework for the messaging strategy, instead of letting the system invent tone from scratch. This gave the model a research-backed way to reason about what kind of nudge might fit different mentoring contexts — accountability, urgency, guidance, encouragement, shared identity, social proof, or reciprocity.
Each match type started with a ranked set of persuasion priors. In this context, a prior means the system’s starting assumption before live context is added. For each match type, I ranked the persuasion principles most likely to fit that relationship, then used that ranking as the baseline score the formula could adjust.
For example:
The important point is that these priors were not fixed rules. They were starting assumptions. Triggers and signals could shift the outcome.
For example, a peer mentorship message may normally start with liking or unity, but if there is a hard deadline, scarcity may become the stronger strategy. If there is a milestone, consistency may become more relevant.
This created a system that was structured but still adaptive.
The persuasion principles help predict what type of influence strategy may fit the situation. Therefore, I mapped each principle to a practical messaging lever:
I mapped each Cialdini principle to a messaging lever so the system had a clear bridge from behavioural strategy to email copy. The principle helped determine the type of influence strategy; the lever defined how that strategy should show up in the message. This meant AI was not blindly guessing the tone, tactic, or call to action — it was generating within a selected strategy and set of constraints.
Scarcity became urgency wording, such as a limited time window or upcoming deadline.
Consistency became accountability or goal-progress nudges.
Authority became best-practice guidance.
Liking and Unity became encouragement, relatability, or shared identity.
Social Proof became references to what peers or other participants were doing.
Reciprocity became offering upfront value, such as a checklist or helpful next step.
This mattered because the system was not only choosing a principle. It needed to turn that principle into a message admins could understand, edit, and trust.
In the product model, I defined how the decision logic could translate into an eventual admin workflow: saved email workflows, trigger setup, audience preview, message generation, testing, publishing, scheduling, safeguards, and analytics.
The intended workflow was:
This connected the decision model back to a usable product experience. Admins were not just receiving AI-generated copy; they were managing a controlled intervention workflow where they could review the rationale, adjust the message, approve what goes live, and tune the system over time.
To communicate this direction, I created an early prototype that made the decision model visible for stakeholders. It showed how match type, triggers, and signals contributed to the final score, which persuasion strategy won, and how that strategy shaped the recommended email.
The goal was not to define the final interface, but to make the system concrete enough to critique. Instead of debating “smart emails” in vague terms, we could ask better product questions:
What data does the system need?
What should the admin control?
When should automation stop?
How should the system explain its recommendation?
What should we measure first?
The goal was to support participant progress without pressuring people or hiding the logic behind automation.
Because the system used automation and persuasion-based messaging, safety had to be part of the product model from the beginning.
The system needed to prevent accidental sends, over-messaging, unclear versioning, broken personalization, and manipulative communication patterns.
Key guardrails included:
I defined success through program outcomes, not email output alone: whether smarter nudges could help participants move toward completion, support employee development goals, and reduce the manual effort required from admins.
The primary success metric was:
Increase program completion
More participants finish the program, receive value, and recommend it. This matters because completion is the clearest sign that the mentorship program is helping employees move toward their development goals.
Supporting metrics included:
Decrease admin time spent per participant completion
Admins can support more participants with less manual effort. This matters because mentorship emails are not their only responsibility, especially in a broader LMS or talent development environment.
Decrease participant time to completion
Participants reach value faster because personalized nudges help them understand the next best action and take it sooner.
Improve first-session booking rate
More matched participants complete the first meaningful action. This matters because the first session is the activation point where the mentorship relationship starts becoming real.
Shorten time-to-booking
Participants move from match to meeting more quickly, reducing the risk that momentum drops after matching.
Improve engagement visibility
Admins can understand which triggers, principles, variants, and match types are performing best, making the system easier to tune over time.
I would validate the concept in stages, beginning with whether the four trigger families covered the most important administrative scenarios and how much explanation administrators needed to confidently review and act on a recommendation.
Outcome validation would focus on whether interventions improved first-session booking, shortened the time from matching to the first session, recovered inactive participants, and increased overall program completion. Administrative efficiency would be measured through time spent per successful intervention.
Acceptance, editing, and override patterns would show whether administrators found the recommendations usable. I would also measure how often skip conditions and send caps activated to learn whether the automation was producing outdated or excessive messages.
This exploration shows how I approach ambiguous product complexity: reducing 82 disconnected communication scenarios into a coherent system, designing logic that could scale across 20 primary intervention contexts, and defining eight safeguards before AI-assisted automation moved forward. The work reinforced that useful AI experiences require more than generated output; they need explainable decisions, operational controls, and clear boundaries.