Instances

Instances are provisioned from a Meeting Type and are tracked on the Instances Page. Any edits to a Meeting Type will only be reflected in new instances which are created after the edits are published. A Meeting Type's purpose is templated provisioning of unique copies of itself. These copies are known as Instances.

 

The Relationship between Meeting Types & Instances

 

Meeeting Type Machine-1

 

Minimum requirements to create and activate an Instance are - a Host, a Guest and a designated meeting type. The Host is the Kronologic User on whose behalf, Kronologic is scheduling the meeting. The guest is the contact with whom the Host wants a meeting.

Instances can be created manually from the Instances page or the Contacts page, automatically from a CRM (Salesforce or HubSpot) through Channels, or in bulk using a CSV Upload. If created automatically or in bulk, an instance needs to satisfy the 3 requirements listed above - A Host, a Guest and a meeting type - to be activated.

There are three specific definitions to understand here:

1. An Instance Phase is a broader category in an instance's existence. There are 3 Instance Phases, which are typically referred to together as an "Instance Lifecycle". These three Phases are Provisioning, Active and Final. 

2. Within an Instance Phase, an Instance goes through specific Instance Stages. Several Instance Stages exist within a given Instance Phase. Therefore, an Instance Stage is a sub-grouping of an Instance Phase. An Instance Stage gives information about Instances.

3. Associated with each Instance Stage are Guest Statuses, which are mostly determined by the Guest behavior (response to the meeting invite or the lack thereof). Like Instance Stages, several Guest Statuses exist within each of the 3 Instance Phases. A Guest Status gives information about Guests that have been invited to various Instances.

 

Instance Phase: Provisioning 

In this phase, Instances can be created manually by providing, at the very least, one of the following three attributes - A Host, a guest or a meeting type. This can be done manually from the Instances page of Kronologic. Instances can also be created using the Import Channels feature from a CRM or can be uploaded in bulk, from a CSV file. An Instance lives in the provisioning phase until the Instance is fully assembled, with all the associated validations.

The three Instance Stages that are possible in the Provisioning Phase are:

  1. Initializing: The Instance has not been completely assembled yet.
    Initializing Fault: Kronologic is not able to assemble the instance, as there is a validation failure (for example,  if the meeting type is disabled).
    Initialized: Kronologic has assembled the Instance completely and the Instance is ready for activation.

When an Instance is in a particular Stage in its lifecycle, the guest can be in different statuses too, based on their behavior. During the Provisioning Phase of the Instance, regardless of the Instance Stage, the Guest status is always "Staging". The guest status "Staging" implies that the Guest is ready for meeting attempts and is waiting for Instance activation.

Instance Phase: Active

Once a fully initialized instance is activated, it enters the "Active" Phase. There are two modes of operation within the the Active Phase - Active Scheduling and Manual Scheduling. Active Scheduling is the process in which automation and A.I are at work to automate and monetize a user's calendar. If there is an out of bounds occurrence, Active Scheduling is switched to manual scheduling, and the Host is notified to take control.

In the Active Phase, Instances can be in the following stages:

Queued - When a Meeting Instance is active, Kronologic will compute the best time slot for the meeting based on multiple factors and check the Host’s calendar for availability. If the time slot is available, Kronologic will proceed with the next stage, which is Scheduling. If the time slot is not available in the Host’s calendar, Kronologic will move the meeting instance to “Queued” and will keep checking back on the Host’s calendar every 20 minutes to see if a slot is available. On the Instances page, if the user clicks on the “Last Activity” cell for a meeting, the Instance History dialog box appears. If a meeting is in the "Queued" stage, this dialog will contain an entry “Queued For Retry Until Available Calendar Space”, indicating that the Host’s calendar needs to be cleared up.

When the Instance is waiting for the Host's calendar slot, it is in the "Queued" stage. When the Instance is in the "Queued" stage, the Guest continues in the "Staging" status.

Scheduling - The Instance Stage is "Scheduling" when Kronologic is attempting to schedule the meeting with the Guest. The Instance may have sent a meeting proposal and is waiting for a reply or is making a second or third attempt or the Kronologic AI Engine is not able to figure out the response from the user and the Host is asked to take control etc. The Guest statuses possible at this Instance Stage are:


Awaiting Response - This Guest Status implies that a meeting invitation has been sent to the Guest and the Guest has not responded yet.
Require Host Intervention - When the Guest responds and Kronologic AI is unable to determine next steps based on the guest response, the Guest is set to "Requires Host Intervention" status, which implies that the Host must take some action to resolve the situation
Accept Pending Quorum - This is a place holder Guest status for Meetings with Multiple Guests (coming soon). 
AI Negotiating - This implies that Kronologic AI has responded to the Guest
Host Intervened - This implies that the Host has replied to the guest response or has performed an overriding action

Scheduled - An Instance is in the "Scheduled" stage, when the guest has accepted the meeting invite and the meeting start time is in the future. The only Guest status possible at this stage is "Accepted"

Instance Phase: Final 

When guest behavior brings the Instance to a phase where no further activities are necessary or possible by Kronologic or the Host, then the Instance in a Final Phase. In this Phase, the following Stages are possible:

Completed - An Instance is in the "Completed" stage if the guest accepts the meeting and the meeting end date/time is in the past. The only Guest status possible at this stage is "Accepted"

No Quorum - An Instance is in the "No Quorum" stage if the Guest has declined the meeting or has not responded at all, or has responded and meeting intent is not clear from the response.

Guest statuses possible at this Instance stage are:

Declined - The guest has declined the meeting invite.
Responded Unknown Intent - Kronologic AI has not been able to determine guest intent and is not proceeding with meeting attempts.
No Response - The Guest has not responded at all.

Canceled - When the Host deactivates the meeting manually through the instances page after the meeting has been activated, the Instance goes to a "Canceled" stage.

Instance Stage Diagram

Meeting Instance Stages.vpd

Instance Stage Description Egress & Ingress

Instance Stage

Description

Ingress Stage

Egress Stage

Initializing

Configuration of required elements needed for activation underway.

None

Initialized

Initializing Fault

Initializing Fault

Attempt to assemble element of instance failed. 

Initializing

Initialized

Initialized 

Initialized

Instance elements assembled completely, ready for activation. 

Initializing

Initializing Fault

Queued

Scheduling

Queued

A cause of this status is when the user has their calendar full for his availability in the day range for the Meeting Type. The instance will be Queued and Kronologic will try to reschedule every 20 min until the day range time has passed.

Initialized

Scheduling

Scheduling

Scheduled

Queued

Scheduling

An instance is considered Scheduling when it has been activated to start sending proposals and reviewing responses

Initialized

Queued

Queued

Scheduled

Canceled

Scheduled

An instance is considered Scheduled when the guest has accepted and the meeting will happen in the future.

Scheduling

 

Completed

No Quorum

Canceled

Completed

An instance is considered Completed when the meeting has already happened

Scheduled

Canceled

No Quorum

An instance is considered No Quorum when quorum for this instance wasn’t reached that is, the Guest has not accepted the meeting.

Scheduling

 

Canceled

An instance is considered Canceled when a Host has manually canceled it

Scheduling

Scheduled

 

Guest Status Diagram

Guest Statuses Diagram MGM I1

Guest Status Description Egress & Ingress

Guest Status

Description

Ingress Statuses

Egress Statuses

Staging

Guest status is considered Staging when the instance is being provisioned

None

Awaiting Response

Awaiting Response

Guest status is considered Awaiting Response when a specific proposal is available for a guest to engage.

Staging

Accepted

Declined

Paused

A.I. Negotiating

Requires Host Intervention

Host Intervened

No Response

Paused

A guest status is considered Paused when it goes into Cal Clog or OOO wait period

Awaiting Response

 

Awaiting Response

AI Negotiating

A guest replies to a proposal with an alternate proposal and the Kronologic AI is confident in the guest’s proposal intent. 

Awaiting Response

Accepted

Declined

Requires Host Intervention

A guest replies to a proposal attempt & AI intent recognition confidence is less than defined threshold

Awaiting Response

A.I. Negotiating

Awaiting Response

Accepted

Declined

Engaged No Intent

Host Intervened

Host Intervened

Host has interacted with guest’s response. This can be from a needed required intervention, or from a host intervention within the A.I. Negotiation Delay Period.

Requires Host Intervention: User replies back to recipient or moves invite.

Awaiting Response: Recipient responds and user opens email before Kronologic attempts to negotiate. Interaction with the hidden calendar does not constitute Host Intervened. Users should never  interact with the hidden calendar.

A.I. Negotiating: User opens email thread or moves invite anytime during the negotiating process. 

Accepted

Declined

Engaged No Intent

Accept Pending Quorum

This is a place-holder Guest status for Meetings with Multiple Guests (coming soon). 

Awaiting Response

A.I. Negotiating

Requires Host Intervention

Host Intervened

Accepted

 

Accepted

Host proposal is accepted by guest either though the calendar invite or A.I. detected intent AND Quorum on instance is met

Accept Pending Quorum

Awaiting Response

A.I. Negotiating

Requires Host Intervention

Host Intervened

None

Declined

A declined instance is the result of declining the calendar invite or A.I. detected intent.

Awaiting Response

A.I. Negotiating

Requires Host Intervention

Host Intervened

None

No Response

A proposal completes its defined behavior with no engagement from guest. 

Awaiting Response

None

Responded Unknown Intent

Response detected from the guest, original proposed meeting is in the past, no intent ever detected. Prior possible stages are Requires Host Intervention, and Host Intervened.

Requires Host Intervention

Host Intervened

None

Routing

Routing is how an instance is assigned to a Host. Routing can be done either manually or automatically. Automatic routing can occur at two points in an instances life cycle -

1) When an Instance is first initialized
2) When an Instance is activated

When the routing actually takes place is defined in the Meeting Type. The Meeting Type definition also permits several types of automatic routing logic.

Series vs. Parallel

Two instances associated with the same Contact of the same meeting type cannot be active at the same time. Another way to say this, is two instances of the same type cannot be active, in parallel, for a given contact. However, a contact can have two instances of different types active in parallel.

Additionally a contact can have two instances of the same type, as long as they are active at different times or, in series.

Attempts

Email attempts to set a meeting are defined in the Meeting Type. Each attempt is made by an algorithm designed to optimize for instance throughput and maximizing accept probability. A good estimate is that an instance with 3 attempts will take about 1.5 weeks to fully process, if there is no response. Typically, a consecutive attempt is sent within hours of the previous unaccepted proposal.