Certain types of meetings occur at scale within an organization, Kronologic empowers admin to define these types of highly scalable meetings on the Meeting Type page. A Meeting Type's purpose is templated provisioning of unique instances of itself. Therefore a Meeting Type & an instance have a parent-child relationship. There are 2 ways a Meeting Types provisions a new instance – Manually & Automatically. When done manually, a Meeting Type is associated with a contact on the contact's page causing an initialized instance to be provisioned. Automatic provisioning is accomplished with an Import Channel. Import channels rely on admin defined field-logic to "listen" for a signal to provision an instance of a certain meeting type.
There are two main components of a meetings type, a Type's Attributes, and a Type's Behavior.
Meeting Type Attributes
Value per Meeting
Email Attempt Templates
Subject & Body
Number of Attempts
Meeting Type Behaviors
Minimum Scheduling Notice - Kronologic will not schedule meetings within this window, giving users schedule stability within this period. Default is 3 hours.
Routing Method - How an instance will be routed to the correct user. There are 4 available routing methods.
• Randomly - A user is selected at random.
• Round-Robin - Instances are distributed sequentially across a team.
• External - Kronologic will use an external system to determine proper instance routing.
• Custom Logic - Using fields associated with contacts assigned to the Meetings Type. an Example might be when state = Texas route to user_a. Please remember that this is explicit logic, therefore if there is no logic the system conservatively defaults to not routing the instance. If multiple users have logic that is true for a given instance, the order of the users dictates which user receives the instance.
• Load Balanced (Beta)
• Even Distribution
• Even Distribution - High Volume
Scheduling Bounds (Beta)
Proposal Attempt Window (Beta)
Route on Initialization vs. Route on Activation
Manually associated routing overrides automatic routing - tells users in instances note "manual routing overriding automatic routing to "rep_email"
Consecutive attempts vary in duration between attempts. The system has determines the probability of prior proposal's acceptance has reached a minimum while maximizing total number of accepts over time for a given user before making a next attempt. A good estimate for 2 attempts is around 1.5 weeks. 3 attempts on average take just over 2 weeks, highly dependent on volume per user.