Instances

Instances are provisioned from a Meeting Type and tracked on the instances page. 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 copes of itself. These copies are known as instances.

Minimum requirements to create an instance are are user, contact, and a designated meeting type. 

Instances can be created automatically through the use of channels or manually from the instances page.  If created automatically an instance needs to satisfy the 3 requirements listed above. A user, contact, and meeting type.

 

The Relationship Between

Meeting Types & Instances

Meeeting Type Machine-1

 

 

An Instance can exist in 3 states. These states are typically referred to as an instances "lifecycle". These 3 states are Initialization, Scheduling, and Final. Keep in mind, many statuses exist within a given state. So status and state have a hierarchical relationship.

 

The Instance Lifecycle

3 States of an Instance

Screen Shot 2020-07-15 at 10.24.50 PM

Initialization: During this state instances are created using the 3 required ingredients to manifest their existence. A user, a contact, and & meeting type. These 3 ingredients can be manually or automatically.

Scheduling: Once a fully initialized instance activated in enters the Scheduling state.  There are two "sub-states" with the Scheduling State. "Active" & "Manual". Active Scheduling is the process which automation and A.I. are at work to automate & monetize a users calendar. If there is an out of bounds occurrence Active scheduling is switched to manual scheduling, and the user is notified to take control

Final: An instance that has reached it's outcome is known to be in a final state. A user, contact, or standardized process can be the cause of an instance entering into the final state. Instances in the "Final" state have two sub states. Impending, & Retired, if an instance is impending it has a start time in the future. This instance will not retire until it moves into the past.

 

 Instance Status Diagram

V2.2 Status Description Egress & Ingress

Status

Description

Ingress Statuses

Egress Statuses

Initializing

Configuration of required elements needed for activation underway.

 None

Initialized

Initialization Error

Attempt to assemble element of instance failed. 

Initializing

Initialized 

Initialized

Instance elements assembled completely, ready for activation. 

Initializing

Initialization Error 

Proposal Pending

Queued (Beta)

 

Queued (Beta)

An instance in considered Queued when a proposal attempt is scheduled for a time in the future. This can occur when the AI detects a recipients desire to reschedule at a future date.  Example: an automated Out of Office style response from a recipient which gives an in-office date. A second cause of this status can result from an instance respecting a Proposal Attempt Window.  Example: Behavior for Meeting Type A has defined a Proposal Attempt Window from from 8am to 5pm. A prior proposal for an instance of Type A is recycled at 11pm, therefore will be queued with the next proposal attempt occurring after 8am. Note, the instance start time can be either known or unknown.

Proposal Pending

Initialized

Proposal Pending

Proposal Pending

Instances are considered pending when a specific proposal is available for a recipient to engage.

Initialized

Queued

Accepted 

Declined

Requires User Intervention

User Intervened 

A.I. Negotiating

Queued

A.I. Negotiating

A recipient replies to a proposal with an alternate proposal and the Kronologic AI is confident in the recipients proposal intent. 

Proposal Pending

Accepted 

Declined

 

Scheduling Paused

(Beta)

A Paused instance remains in it’s pre-paused state and limits instance behavior. When an instance is un-paused behavior resumes with the instance respecting any environmental changes that occurred during a pause. 

 

 

Requires User Intervention

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

Proposal Pending

A.I. Negotiating

Proposal Pending

Accepted 

Declined

Engaged no Intent

User Intervened

 

User has interacted with recipient response. This can from a needed required intervention, or from a user intervention within the A.I. Negotiation Delay Period.

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

Proposal Pending: Recipient responds and user opens email before Kronologic attempts to negotiate. Interaction with the hidden calendar does not constitute user 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: Recipient ultimately accepts a manually negotiated invite. 

Declined: Recipient ultimately declines a manually negotiated proposition. 

Engaged no Intent: No intent is detected by Kronologic, recipient does not accept or decline a manually managed proposal. 

Accepted

Instance proposal is accepted by recipient either though the a calendar invite or A.I. detected intent. 

Proposal Pending

A.I. Negotiating

Requires User Intervention

User Intervened 

None

Declined

A declined instance is the result of 

Proposal Pending

A.I. Negotiating

Requires User Intervention

User Intervened 

 

None

No Response.

An instance completes it’s defined behavior with no engagement from recipient 

Proposal Pending

None

Engaged no Intent

Response detected from the recipient, original proposed meeting is in the past, no intent ever detected. Prior possible states are Requires User Intervention, and User Intervened. 

Requires User Intervention

User Intervened 

None

Canceled

An instance is canceled by a user manually from the interface, from an intercept channel, or the system detects another active thread in the user’s inbox prior to proposal attempt.

 

None

 

Routing

Routing is how an instance is assigned to a user. Instances must be routed during the Initialization state.

Routing can be done either manually, or automatically. Automatic routing can occur at two movements in an instances lifecycle.

1) When an instance is first initialized. 

2) When an instance is activated. 

The timing of automatic routing is defined the Meeting Type, as well as several types of automatic routing logic.

 

Series vs. Parallel

Two instances associated with the same contact of the same meeting type can not be active at the same time. Another way to say this, is two instances of the same type can not 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.