Danny Wieder HSO UK Field Service Consultant

When you manually schedule several bookings, it should still be possible to calculate the travel time. You should have a right-click option on the booking (in the schedule board) which calculates the travel time from the preceeding booking, or the Resource start location if this is the 1st booking for the day. The system should then ask whether the booking should be moved so there is no gap between the prior booking and start of travel for the current booking. Alternatively, the second action could also be a separate right-click option.  

The option to re-calculate travel times for all bookings for that day for a specific resource in one operation should also be available, Similarly it should be possible to abut all bookings for the day for that resource. This could be achieved by right-click actions on the white space or anywhere on the board for that day and resource.

The above applies to the hours view.

Customer Assets may change over time. They may be upgraded and become a different product, other field may change, they could move accounts so their external id changes etc. Currently if you look at any Work Order/Incident, it shows you the current asset data. So if you look at an old call and the asset has changed since, you get an incorrect picture. If you re-print a service report it will also show incorrect asset information. This ought to be changed so that the WO and Incident reflects the asset at the time the call is taken. Reports should also use this data instead of current data. This is a standard feature in other FS systems. Ideally an Asset's change history, including account and agreement moves etc, should be stored separately and accessible from the Asset record.

Ability to have multiple visits/resource bookings for a single work order to be carried out consecutively, not at the same time. i.e. An Installation Work Order which requires 3 bookings: a. Initial Site Survey, b. The installation visit, c. a Quality control visit. The structure to define these can be achieved via a Requirement Group template - they need to have a requirement each. However they must not be booked for the same time as they happen consecutively. When you book each of them, you need to also see the other related requirements.

Some customers (key accounts) are considered more important than others. When scheduling two identical work orders (same distances, priority etc) the one for the more important customer needs to take precedence and be given a higher score by RSO. Need the facility to have an account rating against the service account (or it's parent). Each rating needs to have a weighting which then affects the score for bookings scheduled for it by RSOI. So if you have a Rating of Key Account with a weight of 10 say vs a Standard Account with a rating of 2 the Key account needs to be given a much higher priority/score by RSO.

Currently a technician can move a work order from any status to any other status. In reality there is a natural progression of statuses. At it's simplest this is Travelling --> In-Progress --> Complete. Under specific circumstances you may have 'Travel Home' after 'Complete' or you could have a 'Break' at some stage. But some status changes do not make sense and should not be valid. Examples are: In-Progress --> Travelling or Travelling-->Complete. These should not be allowed. It should also be possible to change the status by pushing a button or flipping a switch rather than having to select it from a drop-down list as this is quiet cumbersome to use.

When you create a WO directly, or update the primary indent type on the WO it takes the duration correctly from the duration of the incident type whether there are tasks or not on the incident type. When you create the WO by converting a Case to a WO it takes it from the tasks attached to the Incident type. If there are no tasks with a duration, the WO Primary incident Estimated duration is then zero even if teh incident type itself has a duration. This needs to be consistent and a WO created from a case should also have the duration set to the incident type duration even if there are no tasks on the incident. This would be the correct behaviour as organisations often do not need tasks on incident types.