Introduction
Certain types of meetings occur at scale within an organization, typical examples could be a Product Demo, Quarterly Review etc. Kronologic empowers administrators to define these types of highly scalable meetings on the Meeting Types page.
Defining a meeting type saves users significant time usually spent on creating meeting invites and negotiating a time to meet with a prospect or contact. The dynamic nature of the meeting types allows users to customize and personalize meeting invitations and email copy with ease.
Another advantage of defining meeting types is that users can create multiple meeting instances of the same meeting type with just a few clicks. That means that users can initialize 100 individual meeting instances with 100 different prospects once a Meeting Type is defined. A Meeting Type's purpose is templated provisioning of unique instances of itself. Therefore a Meeting Type & an instance have a parent-child relationship.
Meeting type parameters can be described as below.
Note : For the rest of this post, a “user” is a Kronologic user and a “contact” is the sales lead/prospect for the user.
Per Meeting Value
Kronologic prioritizes valuable meetings. To do this, a meeting type has a “Per Meeting Value” that associates monetary value to each instance being created. This allows users to easily calculate the approximate worth of each accepted meeting, thereby allowing users and admins to more accurately analyze the ROI of the time they’re spending with customers each day. Read more about Calendar Monetization here.
Meeting Type Library
Library can be thought of as a menu for meeting types. The desired meeting type from the library can be copied by admins to my types for further modifications desired.
There is no limit on the number of meeting types that can be created in the platform.
Meeting Type Status
A meeting type status can be set to active or inactive. When a meeting type is inactive, no meeting instances of that particular meeting type can be processed. In other words, meeting instances for inactive meeting types can be initialized but in order to activate them and have the meeting invite sent out, the meeting type itself needs to be set to active.
Meeting type elements
Meeting type elements are at the center of defining the template and behavior for meeting types. The 3 elements include Meeting Attributes, Meeting Behavior and Channels.
• Meeting Attributes
The meeting attributes section allows users to define the calendar invitation, email that the contact will receive, multiple touchpoints through email attempts and a response if the contact declines the invitation.
Kronologic provides multiple dynamic field “tokens” including Contact name, Contact Account, User Name etc. as placeholders in the meeting type template that allow automatic personalization of the meeting instances for respective contacts/leads.
The calendar invite template defines the invite that will be used for each touch point. If a meeting instance is declined by the recipient, and no other information is given - no accompanying text saying “I’m not interested” or “I’m the wrong person to speak with” for example - the template you’ve created for the “If declined” scenario will be sent and any subsequent attempts to schedule with that specific contact will be halted. Setting up an “if declined” template is an optional step.
Scheduling Attempts
The duration between an initial attempt and subsequent attempts varies. Each attempt is made by an algorithm designed to optimize for instance throughput and maximize accept probability. A good estimate for the total time that will elapse for 2 attempts is around 1.5 weeks. 3 attempts on average take just over 2 weeks. Note, this timing is highly dependent on lead volume per user.
Typically a subsequent attempt is sent within a few hours of the previously proposed (but unaccepted) meeting time.
• Meeting Behavior
The meeting behavior section is something very specific to users and teams within the sender’s organization. The meeting behavior section allows admins to select a team for that meeting type, define when and how the new instances will be routed within a team and other meeting specific parameters. Let’s check them out one by one
ο Team
For specific meeting types, users can associate different teams. For example, let's say we define a meeting type “Demo”, the associated team could be the sales team whereas for a meeting type “Client Onboarding”, we may have a different team.
Once a team is chosen, users can see the active members in the team.
Note that a team corresponding to a meeting type may not necessarily belong to the same department. The team members basically are the attendees necessary for that meeting type.
ο Route on initialization vs. Route on activation
Once a team is associated with a meeting type, routing defines how the meeting instances will be routed or assigned to different team members.
• Route On Initialization: The routing to associated team members happens as soon as the instances are initialized.
• Route On Activation: The routing to associated team members happens as soon as the instances are activated.
Manual routing overrides automatic routing. This means that if an instance is routed by the platform to a specific user, a user/admin can manually change the user to which the instance had been routed. The system makes this change as a note on the instance itself reading "manual routing overriding automatic routing to .”
The different routing logics are explained in the next couple of topics.
ο Team Routing
Team routing defines how the meeting instances will be routed to different team members within the team associated with a particular meeting type.
• Custom: Custom routing allows admin to set completely customized filters for each user.
An example might be when “State = Texas” route to User A and when “State = New York” route to User B. Please remember that this is explicit logic, therefore if there is no logic the system defaults to not routing the instance - this is done to minimize the risk of routing incorrectly and creating a poor buying experience for any prospects. If multiple users have logic that is true for a given instance, the top-to-bottom order of the users in the “behavior” tab dictates which user receives the instance.
• Email based: Email based routing will route the meeting instance to the lead/contact object owner in Salesforce.
• Random: A user is selected at random for a meeting instance associated with this meeting type for a particular lead/contact/opportunity contact.
• Sequential: Instances are distributed sequentially across a team.
ο Calendar Distribution
Calendar distribution allows a user to set how the meeting instances assigned to them will be distributed on their calendar. The distribution can be set as
• Random: The meeting instances are distributed randomly over the selected day range.
• Random High Volume: The meeting instances are distributed randomly and are stacked. This type of calendar distribution can stack up to 14 meetings at the same time slot.
In case of a double booking a user may have to move the meetings. Note : This type of calendar distribution is helpful for Meeting Types with low acceptance rate or for cold leads that haven’t been contacted for over 3 months for example.
• Front Load: The meeting time proposed will be the first availability of the user, beginning with the next day.
ο Gap
By setting the gap users can tell the AI how much gap they want between their consecutive meetings. This means that while scheduling meeting instances, the AI will look at the user’s calendar and ensure that the proposed time for a meeting has the required gap from the previous meeting.
ο Duration
This is the duration for the meeting type being defined. For example a demo meeting type could be 30 minutes long and a business review meeting type could be 60 minutes.
ο Day Range
User gets to select the range of days in which the AI can schedule a meeting with the contacts. For example if a user selects “10 To 30 Days Out” as the day range, all the future meeting instances and subsequent attempts will be proposed between 10 and 30 days from the time the invitation is sent.
ο Minimum Scheduling Notice
The minimum scheduling notice allows users to set a duration ahead of the proposed meeting time within which if the contact has not accepted the meeting invite, the calendar invitation is automatically withdrawn from both the user and contact’s calendar. This is useful for preventing last minute meetings from popping up on the calendar.
The default scheduling notice set within Kronologic is 3 hrs. Whatever number a user sets in this field is on top of those 3 hrs.
• Channels
Channels allow Admin to define the logical criteria under which they want Kronologic to do something. The thing that that is done depends on the type of channel used, Import, Intercept or Update.
An Import channel defines the criteria under which Kronologic should provision an instance of a given meeting type. For example, an admin can create an Import channel for their “Demo” meeting type and set the system to create an instance of the “Demo” meeting type whenever a Salesforce Lead object has a Status of New, an owner role that contains BDR and a lead score greater than 80. Similarly, an Intercept channel defines when Kronologic should stop pursuing a prospect. This is very useful should a rep end up getting in contact with the targeted prospect via an alternate method (like a phone call). Continuing with the Demo meeting type example, an admin could create logic that should the Salesforce Lead object’s status changes to “Contacted - Working”, Kronologic will deactivate the Demo meeting instance associated with that prospect. Finally, the update channel ensures the CRM is up-to-date with any updates regarding the meetings status for a lead/contact. All the 3 channels associated with a meeting type can be active simultaneously.
Read more on channels and creating a channel.
Actions
• Copy to my types
Team admins can copy meeting types from Library to My Types. Please note that the meeting types in Library only have the meeting attributes defined. The meeting type behavior and channel options will still need to be configured when a meeting type is imported to My Types.
When a meeting type is copied to my type, the meeting invite template along with Per Meeting Value gets copied to the corresponding meeting type in “My Types”
• Delete
Only the users with edit rights can delete meetings from the Library and My Types.
• Clone
All the meeting types in “Library” and “My types” can be cloned to create exact replicas. The cloned meeting type retains the name of the parent meeting type with the word “Clone” added as a suffix to easily identify the clone. Also, the cloned meeting type retains all the attributes and behavior of the parent meeting type. The cloned meeting type is set to inactive by default and needs to be enabled manually once it is ready to be used.
• Reset
The reset button acts very similar to an “undo” button. Resetting a meeting type in progress rolls back the template to the last published version. This means that if a meeting type is in progress and not published yet, reset rolls back to a blank template. However, if edits are being made to an already published type, reset rolls back the template to the last published version.
• Publish
Once a meeting type is defined with all the elements, it is ready to be published and once published, it shows in the library of Meeting Types and is ready for use.
Role-specific functional permissions for Meeting Types
Each Meeting Type can only have a single team associated with it. However, a team can be associated with an infinite number of Meeting Types.
A default user has visibility (read only) into the Library of Meeting Types and the Meeting Types that have been assigned to the user by the team or org admin. However, a default user can NOT create a new meeting type.
A team admin can create new Meeting Types. A team admin can also copy meeting types to My types for their team and hence has visibility into meeting types associated with their team. A team admin can also edit any of the meeting types.
An org admin however has all the rights with respect to visibility and ability to create and edit meeting types.
Both team admin and org admin can assign meeting types to default users.
