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

[Joshua Chen MTL]

it's been a while..

first, the point of DS is to auto-assign and make sure the job is completed within a time slot, but its not good Customer experience to say we will be there 10;00 am sharp. like when you receive a technician to fix your internet, they never say we will be there 10:15 - we will be there between 10-11 , and try to complete the work within that time.  

• Availability Method

  Use one of the methods to determine appointment availability. The selection depends on the Field Service Management configuration setting in the Assignment method for tasks field: > Number of appointments per slot: Define a specific number of appointments per time slot. Use this availability method if the task assignment method is set to manually. > Scripted: Use the Field Service Management configuration setting to determine availability if the task assignment method is set to using auto assignment or dynamic scheduling. This is the default setting. > Based on capacity: Determine appointments based on the capacity defined in the capacity management settings. This option is available when the Task Table is selected as work_order and Field Service Capacity and Reservations Management plugin is installed.

• but APT booking is by time slot (so on the WOT, it populates the window start/window end)
  • meaning that the job has to be booked during that time slot (dispatcher pov), and completed before window end (if fixed window= true, see below)
  • DS wil update the scheduled start based on xyz variables such as travel estimate (your config), and could change it to 10:15 (if window start/end is 10-11 as configured in your apt service)
• you can try playingw ith  wm_task.is_fixed_window = true
  • If set, this would not let you have an Estimated End that is after the Window End. Basically, it forces the work to be started and completed within the Window Start and Window End.
  • Task must be completed within the provided window - if not possible, do not schedule this task
  • BUT DS could still change the scheduld start
• OR you could try ignore travel = true (theres a sys property), then DS will be closest to the ''we will be there 10 AM sharp''. but then now you remove ''time travel'' from your criteriaé i havent tested with a lot of data, only isolated use cases and it worked, but again to omany variables.
• if you want real capacity, you need capacity managemnt with apt booking
  
  from my notes, all wot fields updated by apt process

Label	Name	Description	Comment	APT
Estimated end	estimated_end	Date when the work on the task will end. The date is automatically calculated based on the Scheduled start and Estimated work duration.	Estimated End is read-only and set as Scheduled Start + Estimated Work Duration.	Create/Update
Estimated work duration	estimated_work_duration	Estimated amount of work time. The duration cannot exceed the total time of the window. This field is automatically set to an hour. If the task is in the Draft or Pending Dispatch states, you can edit this field. Time that would be taken by the WOT to be completed. How much time will tech be onsite?	BR Populate Schedule - New SOT If current.estimated_work_duration is empty or nil, it sets a default of one hour: current.estimated_work_duration = new GlideDuration("00 01:00:00");	Create/Update
Has appointment	has_appointment	02-15 JC: condition in task filter: appointment tasks set to true if was created via apointment booking		Create/Update
Location	location	Geographical area where the work needs to be done. The location is critical for determining the agent assigned to the task. >Inherited from parent WO >If you do not want to use the auto-populated location, you can add an ad hoc location. For more information, see Setting ad hoc locations in work orders and work order tasks.		Create
Parent	parent	Work order this task is assigned to.		Create
Scheduled start	expected_start	Date and time when the work on the task is expected to begin. This field becomes mandatory from the Assigned state onwards. This field indicates the exact time that the task is scheduled to start. It is a more precise time compared to window_start and is used for planning and dispatching purposes. The scheduled_start time should ideally fall within the time window defined by window_start and window_end. (SO)Optimization computed field, indicates the time for starting the task.	Note1: If you have enabled auto-assignment (DS config), the application auto-populates the Start scheduled field with the current date. Otherwise, you must enter the date manually.No auto-assignment: If Qualifier leaves empty, it will autopopulate with current date/time. So enter date manually if job starts in the future. Note2: Scheduled Start can be set manually, or it will get updated automatically when you use Dynamic Scheduling/SO and it makes and assignment, or if you drag and drop a Work Order Task to a agent’s timeline in Dispatcher Workspace. Note3: Scheduled Start cannot be before Window Start	Create/Update
Scheduled travel start	expected_travel_start	Date and time when the agent expects to travel to the site. This field is required when the task is assigned or when the state is Assigned, Accepted, Pending Dispatch, or Work In Progress. An agent cannot be scheduled for two tasks at the same time. However, if a specified time is already allocated to another task, an error message is displayed. (SO)Optimization computed field, indicates the time for starting the travel.	Note1: WOT "schedule travel start" and "estimated end" will be updated by taking into consideration "estimated travel duration" and "estimated work duration" Scheduled Travel Start is read-only and is set as Scheduled Start – Estimated Travel Duration. Note2: the travel start time is automatically set to one hour from the current time. For example, if you save the Work Order Task record at 9:35 am, the scheduled travel start is automatically set to 10:00 am. When the task reaches the Pending Dispatch stage, the default value can be edited.	Create/Update
State	state	Current state of the task. The field is automatically set as users complete the work for each successive state.		Update
Window end	window_end	Date and time by which agent is expected to complete his task. End of the time window established for this task. >Window Start and Window End can be used to constrain the Scheduled Start and Estimated End fields. The elapsed time of the window cannot exceed the value in the Estimated work duration field (Task needs to start and complete within the window when it is fixed.) >The route optimization and auto-dispatch features use this time when calculating the agent's daily schedule. >If Requested Due By is set on parent Work Order (in the future, not current time), it will be used to set the Window End	Note1: BR populate window end based on SLA >Upon task creation, the 'Window end' date is determined by the latest SLA breach date from its parent work order. > Ensure the business rules 'Populate Window End Based On SLA' for Task SLA [task_sla] and Work Order Task [wm_task] tables are active. Similarly, the client script 'Calculate Window End' should be set to true. Note3:SEE SHEET WINDOWS FOR DS Note4: if apt booking "use slot end time as = arrive by", and its 8-11 am, and job takes 1 hour, window end is updated to reflect that extra hour Note5: If 'Fixed window' is active during task creation, business rules and client scripts are bypassed; the 'Window end' remains unchanged. For work orders generated from appointments with associated SLAs, the 'Window end' time is based on the appointment, not the SLA.	Create
Window start	window_start	Start of the time window that is established for this task. Set by default to current time at created time of the Work Order Task. Route optimization and auto-dispatch features are used this time when calculating the agent's daily schedule. window_start: This field represents the earliest time that a task can begin. It defines the start of the time window within which the task should be completed. Essentially, it sets the boundary for when the task can be started, providing flexibility within a specified range. Window Start and Window End can be used to constrain the Scheduled Start and Estimated End fields.	Note1: Task window start is based on associated transfer order delivery date If a work order task is dependent on a part being delivered, the task's window start will be automatically set based on the delivery by date of the associated transfer order. This ensures that tasks won't be prematurely scheduled. Implications: Dispatchers can be assured that they won't dispatch a task until the required part is delivered, effectively reducing missteps and increasing overall efficiency. Note2: SEE SHEET WINDOWS FOR DS Note3: Test result if entered manually: (1) if you create a WO, and put a dat/time in  the future for  requested du by, it automatically populate     > window start (current date/time)      > window end  (WO request du by date/time) (2) if you create a WO, and enter current date/time, only updates window start on WOT (3) if you create  WO and leave requested due by empty, it populate WOT window start with current date/time (1)(2)(3) if you update request du by, it will not update WOT fields (BR on insert) Note4: (1)For unassigned work orders, the 'Window start' date on tasks adjusts to the transfer order's delivery date. (2)The business rule 'Sync up Delivery Time with WOT' needs to be active for synchronization (3)If multiple transfer orders have mandatory part requirements, the 'Window start' adopts the latest delivery time among the transfer orders. (4) Only mandatory part requirements influence the 'Window start' date based on transfer orders. Still, users retain the flexibility to manually adjust the 'Window start' date as needed. Note5: The Window start date is not updated if the work order task is one or more of the following: (1) Associated with an appointment, (2) Fixed Window (3) Window end is populated and is before the delivery by date (transfer order)	Create

[MichaelT2746638]

thanks for the info.

we can't ignore travel completely because we don't want users picking appointments where our agents have no chance of making it on time.

and we're already setting the is_fixed_window flag on the WOT to true.

i'll look through the other settings to see if we can make something work.

[Joshua Chen MTL]

@MichaelT2746638  Okay, pls update the community if you find a way/workaround.

Dynamic scheduling OR schedule Optimization uses the window start/end and travel estimate/work estimate and other data points to define the scheduled start. You can look into the script include if you want to understand the code behind it.

Unfortunately, DS/SO is not built to say we will be there at 10:15 sharp. Only manual assignment work in this case.

This is bad/not best practice apt booking/ customer experience - any chances you can review your process instead? 

[Skylar_Barth]

Hey Michael,

If the customer you are working with has Impact you can request the CSM to open an access to experts request for more support.

I am trying to understand the use case here as well. How are customers self booking apts? On portal?