ServiceDesk 4.7.71 Update 01/07/14

This is a big one. 

It's one of the items that, from the page's inception, has been in in our "Vote on Project Priorities" webpage (go tomy.rossware.net, and pick this option to see votes and cast yours).  It's the first project-item from that list to be fulfilled (a few other big ones are pending fulfillment very soon). 

In a nutshell, this item/project involves the fact that where you are exposing scheduling availability to third-parties (e.g., to ServiceBench via the SBDL utility, to ServicePower via the SPDL utility, etc.), there is  a natural preference to "hold back" some of your capacity for your own COD-scheduling purposes.   After all, it is much better to harness your techs' capacity doing higher-paid COD work, as opposed to less profitable warranty and or contract-service work. 

Since the DispatchLink utilities were first built, they have included an option to direct-specify how much availability you wish to hold-back from exposure/offering, to the entities involved.  However, these settings have been relatively "stupid," in the sense that whatever holdback value as is specified applies across-the-board, to all zones, all time-segments and all dates.  This across-the-board holdback scheme has really failed to adequately address need.  It's not only because you might prefer different holdbacks for different zones and/or different time-segments; even more seriously, scheduling availability is a little bit like fruit: you grow more anxious to use it up as its expiration grows nearer. 

To state the above another way, if you're looking at a date ten days out, you may estimate there's a good chance you will be able to self-fill 60 percent of its capacity via your own-scheduled COD jobs.  Thus, for a date that distance out, you may want to holdback 60 percent of your availability, from exposure to third-parties.  But consider a date just five days out.  If you have not by now filled 60 percent of that date's capacity (and with your own jobs), you may estimate it as less likely you will manage to do so, and may welcome more jobs from third-parties to help fill the vacancies.  Hence, you might want to reduce your holdbacks to 40 percent.  Now consider a date just one day out (i.e., tomorrow).  If tomorrow's vacancies are not otherwise filled, you may welcome any jobs (even if from third parties) that can manage to fully harness your resources.  So, for tomorrow, it's possible you will want to set your holdbacks at zero. 

The bottom-line is that, in the real world, intelligence dictates reserving more for dates further out, and reserving less for dates closer in (and likely according to some sliding scale). 

As mentioned, until now, our holdback schemes had no basis via which to incorporate such intelligence.  Now they do. 

If you go to ServiceDesk's ZonePlanner interface (Shift-F5-->then click on the "Show Planner" button), you will see it now has a new settings section:

With the default/standard option selected there, the interface shows and works just as it has historically.  If you select the second and new option, however, the area where you could prior alter capacities for particular calendar dates changes from something similar to this (varies somewhat depending on your setup):

To this:

As you can see, it's setup to allow you to specify holdback values individually, for each and every scheduling cell (i.e., zone-and-time-segment combination) -- and according to quantity of days out, varying from today and stretching to two weeks distant.  If you float your mousepointer over, you'll see there are ToolTips to guide you in more particulars. 

Most specifically, if you place a whole-number in any cell, the system will then holdback that discrete quantity from your indicated capacity otherwise, specifically as concerns  any offering to applicable third-parties.   

Example:  Suppose in a given scheduling pocket you have allocated a capacity of 10, and for the same pocket you indicate a holdback (as applicable for the relevant quantity of days out) of 3.  It means, so far as offering pocket-relevant scheduling slots to third-parties for that slot, the system will figure capacity is 7 (10 minus 3).  Thus, if the actual burden scheduled is, say, just 5, the system will offer 2 slots available (7 minus 2).  But if the actual burden scheduled is 7 or more, it will offer 0 slots. 

In the alternative to placing a whole-number in any slot, you may instead place a decimal-fraction.  A decimal-fraction is any number that is greater than 0 but less than 1 (e.g., .2, .37, .9).  It is a mathematically perfect way to dictate a percent when applied mathematically (i.e., .2=20%, .37=37%, .9=90%).  Use this method if, instead of wanting to holdback a discrete quantity, you instead wish to holdback a particular percent. 

Example:  Consider the same scheduling pocket as above described.  If we indicated a desired holdback of .3 (as opposed to 3) exactly the same result would obtain, so long as capacity was precisely 10 (.3 of 10 = 3).  But what if capacity was instead set at 12.  A holdback of 3 (whole number method) would remain a holdback of 3.  A holdback of .3, however, would now result in effectively holding back 4 (.3 times 12 = 3.6, which rounds to 4). 

Depending on circumstances, you may find the whole-number method more effective for your purpose, or the percent method.  Each is provided so you can choose whichever fits best. 

At this moment, just one of the DispatchLink utilities has been updated to use the values as may now be created via the the above-described (and just-now augmented) SD interface.  It's SBDL (aka SB-DispatchLink).  We will update others in the near future. 

Within each such utility, the ability to use the old (comparatively "stupid") method will persist, and control, until and unless you create one or more non-zero settings within the new SD interface.  What happens, essentially, is the utility will look for any non-zero values there.  If it finds even one, it will say to itself: "Aha, we're using the intelligent holdback method."  Based on this, it will change modes.  Instead of using its own ("stupid") settings, it will use what you have created in your SD-ZonePlanner interface. 

To make it appparent which basis it is using, SBDL (Ver. 4.5.55 and forward; other utilities again to follow) will change its interface slightly.  Specifically, so long as you have checked the option to upload availability, it will change the section where you'd otherwise specify un-augmented/"stupid" holdbacks from within it, from this:

to this:

As you can see, the section is disabled and semi-blanked -- so as to make it visually obvious it is having no controlling effect.  Again, you will not see this until (and unless) you have specified one or more non-zero holdback values from within SD (and unless you've updated to a utility that incorporates the improvement; for SBDL it's Ver. 4.5.55 or above).