It seems PSO is scheduling 2 calls on top of one another when the duration and plan start times show that they cant be that close
Here is the PSO Screen
PSO screenshot
The first task that was assigned was done so at 4:30PM On 8/6/20 to start on 8/7/20 @ 8:05AM. 120 Min duration
At 5AM on 8/7/20 it assigned another call to the same user for 7:30AM. Even though duration is 123 minutes, PSO expects the user to complete the newly assigned task and drive to the next task within 30 mins?
This has happened a few times to different users. Not all users are advising if this has happened. Any insight is apprecaited
Best answer by anmise
It seems PSO is scheduling 2 calls on top of one another when the duration and plan start times show that they cant be that close
Here is the PSO Screen
PSO screenshot
The first task that was assigned was done so at 4:30PM On 8/6/20 to start on 8/7/20 @ 8:05AM. 120 Min duration
At 5AM on 8/7/20 it assigned another call to the same user for 7:30AM. Even though duration is 123 minutes, PSO expects the user to complete the newly assigned task and drive to the next task within 30 mins?
This has happened a few times to different users. Not all users are advising if this has happened. Any insight is apprecaited
It looks like both of these calls have been manually assigned and fixed to resource and time i.e. it’s not PSO that has schedule it this way.
It seems PSO is scheduling 2 calls on top of one another when the duration and plan start times show that they cant be that close
Here is the PSO Screen
PSO screenshot
The first task that was assigned was done so at 4:30PM On 8/6/20 to start on 8/7/20 @ 8:05AM. 120 Min duration
At 5AM on 8/7/20 it assigned another call to the same user for 7:30AM. Even though duration is 123 minutes, PSO expects the user to complete the newly assigned task and drive to the next task within 30 mins?
This has happened a few times to different users. Not all users are advising if this has happened. Any insight is apprecaited
It looks like both of these calls have been manually assigned and fixed to resource and time i.e. it’s not PSO that has schedule it this way.
@anmise which event states that? The changes were done by PSO, you’ll see the changes made by PSO in the event list which is what happens when PSO makes a change. Yes if a user makes a change in PSO it will still come over as PSO making that change and not the user. but in this case we dont have anyone working at 5AM to make this change. we checked the logs and no one was logged in at that time. If by some chance it is done manually, shouldnt PSO not allow 2 calls to overlap each other?
@anmise which event states that? The changes were done by PSO, you’ll see the changes made by PSO in the event list which is what happens when PSO makes a change. Yes if a user makes a change in PSO it will still come over as PSO making that change and not the user. but in this case we dont have anyone working at 5AM to make this change. we checked the logs and no one was logged in at that time. If by some chance it is done manually, shouldnt PSO not allow 2 calls to overlap each other?
You can tell by the white lines on the left hand side and underneath the activities that they were fixed to a datetime and resource. They may have been automatically committed based on some rule, but they have not been scheduled like this by PSO.
When we went live, We found that PSO was moving already committed calls so we put a rule in place that when a calls gets committed, it also gets fixed. So essentially every committed call becomes a fixed call.
So if this is the rule that is causing this issue - we can remove it. But then we will have the issue again where PSO is going to move already committed calls.
When we went live, We found that PSO was moving already committed calls so we put a rule in place that when a calls gets committed, it also gets fixed. So essentially every committed call becomes a fixed call.
So if this is the rule that is causing this issue - we can remove it. But then we will have the issue again where PSO is going to move already committed calls.
Correction - we did not put a rule. We update the task status code tablet to have fixed commitment and fixed person once assigned
