EN
Try for free

Matching algorithm

Matching you can show your working for.

Write rules on the fields you already collect, give each one a weight, mark the deal-breakers mandatory. Mentornity scores every mentor–mentee pair, ranks the suggestions, and puts both profiles in front of you before anything is committed.

Try Mentornity for free Talk to us

Free for up to 10 users · No credit card · Rated 4.7/5 on Capterra

Match details: both profiles, the score, and which rules did the work.

Mentor–mentee matching in Mentornity is rule-based and deterministic. You define rules that compare a mentor profile field with a mentee profile field (same department, similar skills, more years of experience) and give each rule a weight. Every pair scores the weight of the rules it satisfies divided by the weight of all rules, times 100. A pair that fails a rule you marked mandatory is removed from consideration rather than penalised. Nothing becomes a match until somebody approves it: an admin, or the mentor, depending on how you set the program up. Run the calculation twice on unchanged data and you get the same suggestions both times.

The algorithm

A rule is four decisions

Rules are built on the additional-information fields you define for mentors and for mentees, the same questions people answer when they join. There is no second matching questionnaire to keep in sync.

  1. 1

    The two fields

    One field from the mentor form, one from the mentee form. They need not be the same question: “Sector I work in” can be compared against “Sector I want to move into”.

  2. 2

    The comparison

    How the two answers are judged: Same, Different, Similar, Equal, Greater than, Greater than or equal, Less than, Less than or equal.

  3. 3

    The weight

    How much this rule counts. The default is 1; the editor takes 0.1 to 100 in steps of 0.1. A rule at 3 moves the score three times as far as a rule at 1.

  4. 4

    Mandatory, or not

    A mandatory rule that fails takes the pair out of the running altogether instead of costing it points. That is the difference between a preference and a deal-breaker, and the algorithm treats them differently.

Eight comparisons, narrowed to the ones that fit

The list of comparisons you are offered depends on the two fields you picked. Choose a number and you get the numeric ones; choose a multiple-choice field and Similar appears. Two fields with no comparison in common cannot be made into a rule at all. The second dropdown simply will not offer them.

Same
The answers match, ignoring capitals and stray spaces. Multi-select answers count as the same when they hold the same options in any order. An empty answer on either side never counts as Same.
Different
The answers do not match. This is the rule to write when the point of the program is to pair across a boundary rather than within it.
Similar
Two multi-select answers share at least one option. “Python, SQL, Figma” is similar to “Figma, After Effects”.
Greater than, or equal
For numbers and star ratings: the mentor’s figure is above the mentee’s. This is how “the mentor has more experience than the mentee” gets written down.
Less than, or equal
The mirror image, for the fields where the smaller number is the one you want on the mentor’s side.
Equal
Numeric equality, for the cases where the two figures should be the same rather than merely close.

Custom rules pin each side to a value

A standard rule compares two fields with each other. A custom rule compares each field against a value you choose: the mentor’s department is Engineering and the mentee’s goal is Career change. Both halves must hold for the rule to count. Custom rules carry the same weight and the same mandatory switch as standard ones, and they are how you handle the specific combinations a general rule would get wrong.

  • Pick the mentor field and its value, then the mentee field and its value
  • Weight and Mandatory behave exactly as they do on a standard rule
  • Choice answers are matched by their label, so the two forms need not share option IDs
  • Saving a rule you already have is caught and flagged rather than duplicated

How a pair becomes a number, and numbers become a shortlist

Two steps: score every possible pair, then decide who gets whom. Both are deterministic, which matters more than it sounds. “Approve all” has to save exactly the pairs you were looking at when you pressed it.

Match score

weight of the rules the pair satisfies ÷ weight of every rule × 100

Mandatory rules count in the denominator whether they pass or fail. The score is stored unrounded and shown rounded to the nearest whole percent. Define no rules at all and every pair scores 100%.

Four rules, one pair

  • Focus area · Same × 3 Matched
  • Languages · Similar × 2 Matched
  • Years of experience · Greater than × 1 Matched
  • Department · Same × 1 Not matched

6 of 7 weight satisfied → 85.7% → displayed as 86%

Scarcity breaks the ties

Pairs are taken highest score first, but when two score the same, the mentee with fewer candidates goes first. A mentee with one 80% option is not out-bid by a mentee who has three.

Nobody is dropped to flatter the average

After the first pass, Mentornity tries again for every mentee still without a match, rearranging a chain of up to three existing pairs to make room. Then up to six more passes accept only the swaps that raise the total across the whole program.

Ranked, and capped

Suggestions arrive sorted by score. A pair scoring 0% is never suggested. An active pair is never suggested again, and whether a finished pair may come round a second time is a setting. Each side stops collecting suggestions at the matching limit you set, where 0 means no limit.

Before you commit

Two windows, two different questions

One answers “is this pair right?”. The other answers “who else could this mentor take?”. Both open over the list you were working in, and neither creates anything until you press the green button.

Field by field, tinted by the rule that touched it.

The comparison window: is this pair right?

Opens on a suggested pair, an active pair, or a pending request

Both profiles are laid out side by side, field by field, in the order you defined them. Every field a rule touched is tinted green where the rule matched and red where it failed, with “Matched” or “Not matched” written underneath. The rounded score sits between the two columns. It is the same window whether you arrived from a calculation result, from the Matching List, or from the pending-request link on your dashboard.

  • Both profiles in full rather than a summary, with choice answers resolved to their labels and star ratings drawn as stars
  • The green and red tinting shows which rules did the work, with no table of rule names to decode
  • The footer says, before you click, whether approving will email the two people, according to your program’s notification setting
  • Approve match creates the pair. Reject only clears the suggestion from your screen; it is not stored

One mentor, every mentee, sorted by score.

The mentor window: who else could this mentor take?

Opens from the + Match button beside any mentor

The mentor stays pinned on the left with their own profile fields. On the right sits every mentee in the program, one row each, scored against that mentor and sorted highest first. If you have not run a full calculation yet, Mentornity scores this one mentor against the whole pool on the spot.

  • One column per mentee profile field, so you can read the answers without opening anybody
  • Search by name, and filter the profile columns: a choice field offers its options, a text or number field a search box
  • Scores show as whole percentages and turn green at 80
  • Mentees already matched to this mentor read as Matched and cannot be picked twice; requests waiting on approval read as Pending
  • Rows load 50 at a time behind a Show more button, and the filters cover what is loaded
  • Choosing a mentee opens the comparison window, and the pair is created there rather than in this list

Approval

Who says yes

Matching Settings decides this, and the choice changes what participants see. Here are the two arrangements where a request waits for somebody.

The mentor approves

Mentor selection: show the list · Start of the process: when the mentor approves the request

  1. The mentee browses the mentor list and sends a request.
  2. The mentor gets the “… Sent You a New Request” email, and it goes out even when the program’s other notifications are switched off.
  3. The mentor opens their Mentees page, where the request carries Accept and Reject buttons.
  4. Accepted, the mentee is emailed that the mentor said yes. Rejected, the mentee is emailed that they can choose someone else, and their request no longer counts against their limit.

What the mentee sees

The button on that mentor turns into “Request sent” and stops responding, and the request is listed under “You have N pending requests”. There is no cancel button: until the mentor answers or an admin steps in, the request stands.

An admin approves

Mentor selection: admin approves pair requests (this fixes the start of the process to approval)

  1. The mentee browses the same list and sends a request. The confirmation dialog tells them an administrator will approve it.
  2. No email goes to the mentor in this mode.
  3. The request lands in the Pending Approval column of the Matching List, and as a count on the admin dashboard that links straight to the comparison window for that pair.
  4. The admin activates or rejects it from the chip’s menu. On activation the mentee is emailed, with the program’s name where the mentor’s would be, because the program is who approved it.

What the mentee sees

Exactly what they would see in the mentor-approval flow: “Request sent”, and the pending list. The difference is invisible from their side, which is why the confirmation dialog names who will be deciding.

A third arrangement skips approval entirely, so the match starts the moment the mentee picks. A fourth hides the mentor list, leaving every pair to the algorithm and the admin. Two caps apply on the mentee side regardless: how many mentors they may end up matched with, and how many requests they may have outstanding at once. Hitting either is refused when they press the button rather than absorbed quietly.

Every change to a pair is on the record

Matching Actions is a table of what happened to which pair, when, and who did it.

Seven kinds of event are written: the match itself, a request sent, accepted, rejected, cancelled, completed, and deleted. Each row carries the mentor, the mentee, the timestamp and the performer. The performer is an admin, the mentor, the mentee, or “System (automatic)” when a scheduled job did it, such as a match reaching the duration limit you set.

  • Written whether the pair came from the algorithm, from an admin adding it by hand, or from a mentee’s request
  • Filter by action type across the whole history; search the loaded rows by name
  • Fifty rows at a time, newest first
  • Notes attach to a single event and stay inside the admin panel. No participant screen or email carries them
  • The note box is offered the moment you approve a match, with Skip as an equal option

Match, request, accept, reject — and the note explaining it.

What the matching will not do

Four things worth knowing before you build a program around it.

It reads form answers, not behaviour or calendars

Rules run on the additional-information fields of the mentor and mentee forms. Availability, time zone, meeting history and free-text bios are not inputs to the score. Date fields cannot be used in a rule at all, because no comparison applies to them.

Rejecting a suggestion teaches it nothing

Reject clears a suggested pair from your screen. It is not stored and not remembered: recalculate and the pair comes back. To keep two people apart for good, write a rule that separates them.

Invited people can be compared but not matched

You can open a comparison with somebody who has not accepted their invitation yet, and the score is real. Approving it fails, and Mentornity says which ones failed rather than reporting a save that did not happen.

The score is a shortlist, not a verdict

With no rules, every pair scores 100%. With one rule, every pair scores 0 or 100. The number is only as good as the rules behind it, which is why the comparison window shows you two profiles instead of only a percentage.

Frequently asked questions

How does Mentornity’s mentor matching algorithm work?

You write rules comparing a mentor profile field with a mentee profile field (same department, similar skills, more years of experience) and give each rule a weight, which defaults to 1. Every pair scores the weight of the rules it satisfies divided by the weight of all rules, times 100. Pairs failing a rule marked mandatory are removed rather than penalised, pairs scoring 0% are never suggested, and a pair already active together is never suggested again. Suggestions arrive ranked by score, and the same data always produces the same result.

What is the difference between a standard rule and a custom rule?

A standard rule compares two fields with each other: the mentor’s years of experience greater than the mentee’s. A custom rule compares each field against a value you fix: the mentor’s department is Engineering and the mentee’s goal is Career change. Both carry a weight and both can be marked mandatory. Standard rules describe the general shape of a good pair; custom rules handle the specific combinations that general shape would get wrong.

What does a mandatory matching rule do?

A mandatory rule removes the pair from consideration when it fails, instead of costing it points. Use it for constraints that make a pairing pointless no matter how well everything else fits: no language in common, a direct reporting line, the wrong cohort. Two or three weighted rules plus one mandatory rule usually beats a long list of equally weighted criteria.

Can mentees choose their own mentor in Mentornity?

Yes, and you decide who confirms the choice. The mentor list can be shown or hidden; when it is shown, a match can start the moment the mentee picks, wait for the mentor to accept, or wait for an admin to approve. Both approval modes cap how many mentors a mentee may request at once and how many they may end up matched with, where 0 means no limit.

Can we see why a pair was suggested?

Yes. Opening a suggestion shows both profiles side by side with the score between them, and tints every field a rule touched: green where it matched, red where it failed. Approving, rejecting, accepting and completing are all written to Matching Actions with the timestamp and the person who did it, and you can attach a note that stays in the admin panel.

Does the matching work for group mentoring?

Yes. When the mentee side of your program is groups rather than individuals, rules run against the group’s own information fields and the mentor window lists groups instead of people. One difference to know: the pending-request shortcut into the comparison window is switched off for group programs, because that window is built to compare two people.

Try it on your own program

Import your people, write two rules, press Calculate, and look at what comes back. The free tier runs a real program of up to 10 users and the matching in it is not cut down. If you would rather settle the criteria first, the guide below compares the three matching methods and the criteria that actually predict a good pair.

How to match mentors & mentees →

Run mentoring people actually show up for

Set up your program, invite your people, and let Mentornity handle matching, scheduling, and follow-through. You watch the health of every relationship from one dashboard.

Try Mentornity for free Talk to us

Free to start · No credit card · Setup in minutes