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.
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.
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:
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.
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"
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
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 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 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.
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.
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.
