When using ServiceTrade to manage your scheduling, particularly in the area of recurring services, or services that repeat with some frequency (Annual, Semi-Annual, Quarterly, etc.), it is important to understand the difference between:
1. Rescheduling a one-time occurrence of a service that is generated by a "parent" recurring service
(Go straight to Example 1 for the above)
2. Rescheduling the entire underlying frequency/recurrence cycle of the entire recurring service for all time going forward.
(Go straight to Example 2 for the above)
We have a recurring portable extinguisher service, that is next due in July 2016, and is set to repeat on a quarterly cycle. If we want to change anything about the underlying recurrence cycle, or reschedule the next upcoming service AND have all future instances of this recurring service update to keep the same predefined frequency -- we need to do this to the service from that service's Location Page.
Using the recurring service above as an example, we will go through a couple different scenarios detailing how you might potentially want to manage this service (or any similar service or a recurring nature in your account).
Changing a single service's due date -- without changing the due dates of all future services on that frequency.
For this example, "today" is sometime in mid-May 2016. We can see looking at our recurring portable extinguisher service above, that this quarterly inspection is due in approximately 2 months -- in June 2016. In this example, we are interested in the following outcome:
- We want to reschedule the upcoming quarterly extinguisher service and postpone it by a month. Perhaps our customer is doing construction and will be closed during the month of June, so we want to go out and make sure that quarterly inspection is done ASAP after the construction is complete in the first week of July.
- We only want to change the June 2016 service's due date. Going forward after that, we would like this quarterly recurring extinguisher service to continue being due on the same originally set frequency (and not have all future instances of this service postponed or offset by 1 month). So essentially, we want to move the June 2015 service to July 2016, but we still want the following service to be due on the same quarterly frequency (i.e. just because we are moving June's service to July, we still want the next service to be due in September 2016, and not October 2016).
Refer to the screenshots and the animated GIF below, which demonstrate one (of several possible ways) in which you could change the dueness of an upcoming one-time instance of a recurring service -- without changing the underlying frequency of all future occurrences of this service.
1. ON THE CUSTOMER'S LOCATION PAGE, CLICK THE "ADD A JOB" BUTTON
2. SCHEDULE A JOB FOR YOUR UPCOMING SERVICE -- AND BE SURE TO SPECIFY WHEN YOU WOULD LIKE THE JOB TO BE DUE
Summary of the steps performed in the above animation:
- Click "Add A Job" on the customer's Location Page
- Check the service from the list that we are assigning to this job
- Go to the Service Due dropdown menu, select a "Custom" date range for this services dueness (here we chose: 7/1/16 - 7/31/16 -- which changes this June 2016 service to be due in July 2016).
- From here, we proceed to finish scheduling the job by choosing: a Job Type, and (optionally) Scheduling Technicians and Scheduling an Appointment Date & Time for this Job/Service.
IMPORTANT NOTE: ADDING SERVICES TO A JOB AND THEN CHANGING THE DUENESS OF THAT PARTICULAR JOB WILL OVERRIDE THE DEFAULT DUENESS OF ANY SERVICES YOU SELECT WHEN CREATING THAT JOB (WHICH IN THIS CASE IS EXACTLY WHAT WE WANT).
3. THE RESULTING JOB THAT WE JUST CREATED CAN BE SEEN BELOW
4. A LOOK AT THE LOCATION PAGE (AND MORE SPECIFICALLY THE RECURRING EXTINGUISHER SERVICE ON THAT LOCATION) AFTER CREATION OF THIS JOB WHICH RESCHEDULES OUR JUNE 2016 SERVICE
EXAMPLE 1 SUMMARY:
The final outcome of our procedure in Example 1 can be neatly summarized by looking at the resulting quarterly extinguisher service on the Location Page after we have made the changes we wanted to.
You can see that we had a quarterly recurring service, that was next due in June 2016 -- then we decided that that one instance of this recurring service couldn't be done until July -- so we created a job, added our upcoming June service to that job, and then changed the dueness for that job (and all the services that we included on it) to be due one month later, in July.
We didn't do anything to the recurring service itself. All we did was take a single upcoming service instance, added it to a job, and then changed when we wanted to have that single service instance due.
The result is what we would expect: we selected one service (from the next due "queue" that our quarterly recurring service generated for us), and then changed when we want to perform that one service. This is why only our June service was delayed by 1-month, and not our entire recurring service's frequency cycle.
Changing the "Next Due" date of an upcoming recurring service AND making all future instances of that recurring service shift by the same amount we shift the "Next Due" service by.
We begin this example with everything in the same "state" as it was in Example 1. Here in Example 2, we also want to postpone our upcoming June 2016 service, by one month, to July 2016. Where this example will differ from Example 1, is that when we postpone the "Next Due" June 2016 service to July 2016, we also want the entire underlying recurring service's frequency to shift forward by one month as well, so that our service is Next Due in July 2016, AND ALL future quarterly instances of this recurring service are postponed by one month also (see the small, green arrows on the above screenshot for an illustration of the intended outcome of this example).
ONE CLARIFYING NOTE BEFORE CONTINUING:
- In Example 1, all we wanted to do was change the "dueness window" of a single instance of a service (that happened to be part of a larger, quarterly recurring service).
- In Example 2, we are more interested in changing the underlying frequency cycle of an entire recurring service -- so that when we delay the "Next Due" service by one month, every future instance of this quarterly recurring service shifts forward by one month also.
While it may seem like accomplishing the above goal would be more difficult, it is actually a lot easier in almost all cases. See the animated GIF below for the simple steps required to move the "Next Due" service forward by one month -- in addition to moving every future recurrence of that service (on a quarterly cycle, in this case) forward by one month as well.
Notice that the end result here -- after following the GIF animation above -- is exactly as we defined above in the image with the green arrows. The entire quarterly recurring service has been shifted forward by exactly one month and is next due in July.
The key to understanding how everything above works is to understand the difference between a recurring service (which is setup and "lives" on a Location Page) and a single instance of a service that is generated by a recurring service (these "single-instances" of recurring services are called "Service Requests").
Ex. 1: The "single-instance", or Service Request, that is generated by a recurring service can have its dueness changed in any way you want. Just keep in mind that any scheduling changes that you make to a single Service Request will only be applied to that one Service Request -- the "parent" Service Recurrence will stay unaltered -- unless you go directly to the Location Page it exists on, and change the "Next Due" date for the entire recurring service.
Ex. 2: The entire recurring service can only be altered by going to its Location Page, clicking the "edit pencil" for that recurring service, and changing the "Next Due" for the entire recurring service as a whole. If you only change the dueness of a single service (by assigning it to a job that alters its default dueness) then this will only change the dueness of that one service. At this point, nothing about the recurring service itself is being changed at all.