Meeting Type Menu


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 

Instance Duration

Email Attempt Templates

Subject & Body

Invite Templates




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)

Calendar Distribution

• Front-load

• Even Distribution

• Even Distribution - High Volume

Associated Team

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"


Scheduling Attempts

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.