The process whereby MeetMax automates the meeting creation is complex and it's worth spelling out the steps and layers.
There is an initial filter. This is important. It establishes the list of people or companies that it will then work on (call them Candidates). Clicking continue shows all the requests that relate to the people in the filter - but its the people/companies that is also important.
The way the algorithm works is that it cycles thought that list of Candidates (as established by the initial filter), in company alpha order, and gives them 1 meeting. Then it goes to the next Candidate and so on. When it gets to the end of the list of Candidates, it goes back to the beginning and gives the top perosn a second meeting and so on.
If a Candidate has only requests for which it is the source - then it schedules the meetings in the order of its own ranking value.
If a Candidate has only requests for which it is the target - then it schedules the meetings in the order of the source's ranking (ie prioritizing requests that were valuable to the other side).
If a Candidate has a mixture of requests, for which is it sometimes the source, sometimes the target, then the algorith, when working on this Candidate, will prioritize by the request ranking, regardless of whether its the Candidate's ranking or the ranking of the one who requested the Candidate. See note e. below.
A meeting is created if
- a time slot works for both requestor and target
- neither side has maxed out its meeting limit overall - or the meeting limit of that automation run
- the target of the request did not decline it, or give it a negative interest rating
- a room is available for possible time slots if that condition is required.
Extra Tools to consider
a. Limiting your run to either
- Approved Requests
- Mutual requests
The purpose here is to prioritize requests that are clearly desired by both sides - ahead of requests that have only been expressed by one side or the other.
b. Setting Limits on Meeting Counts
You can do this by day and by Role. The purpose here to to enforce spreading of the meetings. If ABC Corp was the top meeting choice of a large number of attendees, then ABC would get a disproportionate number of meetings relative to other companies. Setting a meeting limit of 10, say, gives other companies a chance
c. Setting the cap on meetings per attendee in the run. This has a similar effect and is useful if you intend to run the automation process in tranches. It prevents the first tranche of Requestors using up all the slots or tables - and leaves resources for tranches 2 and 3. Set a cap of 5, say.
d. Sub filters. These can be used to narrow the list of requests that is acted upon, for the initial list of Canidates. An example - the initial filter could be Role = Buyer, but the subfilter could be Target Company Tier = 1. So it only schedules meetings with requests for Tier 1 Sellers.
e. If your initial filter yields a list of Candidates who are both the target and the source of requests - but you want the automation to only prioritize the Candidates rankings - then you need to use a sub-filter. If the initial filter was Role=Buyer, then use a subfilter of Source Role=Buyer. This will limit the requests to just those requestors where the Candidates was also the Source.
