Q3 2021
LISTINGS - AVAILABILITY ALLOCATION AND RULES
Listings come into play when your typical appointment subjects (e.g the type of conversations your agents are having with your customers) and the scheduling rules accompanying those, actually differ from case to case depending on a specific item in a list (e.g. list of job postings, list of properties, list of projects, …)
A listing will force the Skedify plugin and Partner Booking Application to handle an extra set of rules on top of the subject planning rules. The possible extra rules are to limit to a certain number of subjects/agents/offices/meeting types for a listing.
With this release of Listings, the following possibilities are added to this powerful feature
Listings is a feature that is available in the Amplify and Magnify packages and needs to be activated by Skedify.
You can find more information here.
AGENT PRIORITIZATION
Agent prioritisation is a feature that allows you to prioritise agents when multiple agents are available.
This comes into play in the following use cases:
Agent prioritisation is a feature that is available in the Amplify and Magnify packages and needs to be activated by Skedify.
You can find more information here.
Incorrect appointment state after customer proposes a time slot in response to an invite from an agent.
Previously, the appointment remained in an outgoing state when a customer proposes a time slot (without auto-accept configuration) in response to an invite/rescheduling request from an agent. This action should actually transition the appointment to an incoming state (meaning that the next action lies with the agent).
Not transitioning the appointment could give the agent the wrong impression that the next action lies with the customer. It would also result in an incorrect webhook event being sent when the agent accepts the proposed time slot (DateCreatedByContact instead of AcceptedByContact), possibly resulting in an incorrect state for integrating systems that respond to these events. (Our ref. SKED-7586)
Incorrect webhook event sent after customer chooses a time slot with an auto-accept configuration, in response to an invite from an agent.
A DateCreatedByContact webhook event was sent instead of a DateCreatedByCustomer event when a customer chooses a time slot with auto-accept configuration in response to an invite/rescheduling request from an agent. This action should actually trigger a DateCreatedByCustomer webhook event.
Incorrectly sending the DateCreatedByContact webhook event could result in an incorrect state for integrating systems that respond to these events. (Our ref. SKED-8051)
Incorrect webhook event sent when agent requests a rescheduling for an accepted appointment.
First a PossibilitiesChangedByCustomer event and then a PossibilitiesRequestedByContact event were sent when an agent requested a rescheduling for an accepted appointment. This action should actually only trigger the PossibilitiesRequestedByContact event to be sent.
Incorrectly sending the PossibilitiesChangedByCustomer webhook event could result in an incorrect state for integrating systems that respond to these events. (Our ref. SKED-8052)
Mandatory question field in the plugin does not recognize input.
Adding a dot (.) at the end of a question label (for a specific subject) that is marked as mandatory resulted in the malfunctioning of the plugin field validation, causing the plugin to keep asking for input while an answer has already been provided. (Our ref. SKED-8165)
Impossible to change the earliest time slot field for a subject to 0 days without changing the latest time slot field as well.
Changing the earliest time slot field for a subject to 0 days without also changing the latest time slot field resulted in an error while saving. This could be worked around by briefly changing the latest time slot field, saving it and then reverting the field back to its old value but is not intended behavior. (Our ref. SKED-8228)