Dispatch Console Driving Time Strange Logic can be improved

Dispatch Console Driving Time Strange Logic can be improved

When in the Dispatch Console the Start Date & End Date are filled and clicked on "Auto-populate" it calculates the Service Time.

However, when I add one our of drive time either before or after and click on "Auto-populate" it adds them both to the End Date. In the calendar it shows the drive time before and after as configured. The Scheduled Date Time field on the work order shows Start Date plus Before Drive Time and the time.

I would like to see that the Start Date is the Same as the Scheduled Date Time. The Logic is that dispatchers don't have to calculate which date/time they actually agreed upon with the client and calculate the drive time to get to the Scheduled Date Time.

If the customer expects the client on for example 15:15 and the expected service time is 2 hours. It would be easier as followed:

Start Time: 15:15 (will also be scheduled Date / Time)

Travel Time before: 1 hour, shows on calendar that travel starts at 14:15 until 15:15

Trave Time after: 1 hour, shows on calendar that travel starts at 17:15 until 18:15

Product Area?
Communities Mobile Field Service Management Preventive Maintenance Reporting & Analytics Work Order Management
What version of ServiceMax are you on?
Summer 16
Fry Chef
Fry Chef

Effectively the drive time is not add logically and also, this information are not displayed properly on the FSR mobile app

On the DC, the start time and end time should be inform the FSR the expected onsite time and the duration of the Work

The drive time should create  events on the FSR mobile app calendar and by this way he should be able to know the expected time onsite and the estimated time to drive to the customer

Drive time.PNG

Line Chef
Line Chef

Due to this issue, we have a lot of misunderstanding in our company as our fielders have no good view on their iPad calendar what is exactly planned for them.

The dispatcher plans travel and labor for a certain work order, but the fielder cannot see these details on his/her iPad calendar view. From the iPad calendar, it is impossible to see when to start at the customer exactly (after some travel) and how many days you have to stay there as labour (drive time) and travel is not split.

Roast Chef
Roast Chef

The problem also is that on the Technicians calendar, they end up seeing their start time as the time in which their travel begins, and not the Start of their Service on the calendar on their Home tab, which shows the Start and End time and is not the Start Date Time. Which leads the Tech's to believe their service starts hours before their actual Start Date Time. When in fact that 3 hr discrepancy for example is their allotted travel time. However, the Email Alert Tech's and customers receive are accurate as this displays the actual Start Date Time.

I have an entire document I created to instruct Dispatchers on how the logic works, it shouldn't be this complicated.

Drive Time for same day arrival:

Scenario:   Drive Time with scheduled arrival at 12:00 PM and 3 hrs. of prior travel the day of the service.

Start Time 12/27/16  = 9:00 AM  (set 3 hrs. prior to the arrival time) - For a scheduled arrival time of 12:00 PM 

End Time  12/27/16 = 06:00 PM 

Travel Day & Service all on the same day: 12/27/16

Drive Time (before) =  Set to 3 hours (this is set to minus the hours required to travel before this service that was used to determine the Start Time, if after set to plus hours.

The service will be scheduled for a Start Time of 12PM on 12/27/16, which both the FSE will see as well as the customer/integrator in their respective email alert, shown below.

Tech's Email:

Tech's calendar view on the Home screen:



Grill Chef
Grill Chef

Schneider Electric

Product Team
Product Team
Status changed to: Not Planned

Service Board behaves in a different way when it comes to start time and travel time: the dispatcher plans the job at the time when the actual working should start, and the system automatically calculates the travel time required and therefore when the tech should leave his or her previous location.

This new behaviour should address the (very reasonable) concerns raised in this idea. Closing it as "Not Planned" simply because we don't expect to change the way DC1 behaves today. 

Grill Chef
Grill Chef

@gabriele_bodda Hi Gabriele, Could you please explain in a little more detail that how will Service Board (which is for the planners) solve the issue highlighted in this idea (which is for the FSRs)? The issue being that the FSR's, in their FSA calendar see the event as one block with the starting time of this calendar event as the drive start time. Hence it causes a confusion between job start time and drive start time.

Imagine this: If you have a meeting scheduled in your calendar from 8AM, you'll assume the meeting will start at 8AM, not that you have to start driving from home at 8AM..

@casher FYI..

Product Team
Product Team

Hi @priyamyo, maybe I misunderstood, but the original idea seems to be all about how DC1 calculates Scheduled Date vs Start Date. Mobile came up later in the comments, and the issue there seems to be mostly that the app does not differentiate Travel Time from Work Time. Could you please create an Idea for that specific problem under the Mobile area? I believe it is already being addressed, but my colleagues will be able to confirm the details.