Dyanmic Scheduling and travel duration

[MichaelT2746638]

Hello everyone,

We're in the process of setting up FSM with a use case to allow customer to self schedule appointments.  All of our appointments are at fixed times (e.g. 8am, 10am, 1pm, etc) with travel duration defined in the sn_apptmnt_booking_service_config records.  We're also automatically assigning an eligible agent to the task. 

With Dynamic Scheduling, the results after invoking the booking api are very inconsistent.  And the system is sometimes not using the appointment time selected by the user.

If the travel duration is way outside the defined travel duration, the booking api will still return a "success", even though no agent is eligible.  A sn_apptmnt_booking_appointment_booking record gets created, but no agent is assigned to the task since no one can actually make the appointment within the travel duration.  While not ideal, we are working around this by just checking if no agent was assigned after booking and then rejecting the appointment time to have the user select a different time.  (long term we're looking into customizing the dynamic scheduling filters used to calculate availability to take into account travel duration similar to how its already doing it during auto assignment after booking) 

However if travel duration is just a few minutes over the allocated configured value, after invoking the booking api, a sn_apptmnt_booking_appointment_booking record gets created with the correct start times and the task is assigned to an agent as expected, but the appointment time on the task (expected_start on wm_task)  is NOT what the user selected, it is shifted by the few minutes over the allocated travel time. (so if travel duration was allocated at 30 mins, but travel was estimated to be 45, a 10am appointment time selection would end up as a 10:15 appointment).

I'm still new to SN's FSM so I'm not familiar with all the various configurations for this and I couldn't find any relevant documentation, but are there settings to control this behavior?  If no agent is eligible due to travel time, regardless if its 2 mins or 2 hours, we'd like for it to consistently "fail" so our workaround can be utilized.  It is also a very bad user experience to pick one time, but then get confirmation for something else.

Thanks,

Michael

[MichaelT2746638]

Hi Skylar,

I'll check with the our team about Impact.

As for the use case, we've written custom integration with the ServiceNow's availability and booking APIs to our customer facing website so they can pick their own appointment times.  Ideally, the system would only present appointment times where a qualified agents is available and automatically assign the WOT to them, without any intervention from our dispatch team.