ServiceDesk 4.8.193 Update 11/03/20

This is an all new dispatch-planning and management tool. It is not intended to replace the DispatchMap and/or ZonePlanner. It's intended to be a robust supplement, an alternate view, a complimentary mode of managing things.

Direct access to the new interface is via Ctrl-F5, as you'll see if you click on "Dispatch Operations" in the ServiceDesk MainMenu (of course you may use your mouse via that menu as another means of accessing the new interface):

Its general appearance is something like this:

Though, of course, your own image will vary, depending on your own techs and schedule.

You may note this new interface is designed to show you, at a glance, what is on your roster for an entire week. Items within each tech's roster as shown for any particular day will spread across the applicable day column horizontally, according to time-frame involved. The system will always show you the current week when initially displayed and, just as it's true in the DispatchMap that you can use PgUp and PgDn to move between days displayed, here you can use the same keys to move between the particular week that is displayed.

The new tool also has a parallels to the Target-Specific functions that are available from a Callsheet or JobRecord. To remind, those are the functions whereby you may right-click on particular targets, within a Callsheet or JobRecord, and see the location or zone to be scheduled within either, respectively, the DispatchMap or ZoneScheduler. In fact, from either context you may then choose the appointment date wanted, and have it auto-insert for you back in the Callsheet or JobRecord.

In particular, we'll here outline what are now three parallel such functions (the first two being ones that have long-existed, and which you should already understand):

1. From a Callsheet or JobRecord, you may right-click in an applicable street-address box, to have the system invoke the Item-Locate function within the DispatchMap. What this does is show you the address location within the DispatchMap, which allows you to deduce the most efficient date and time-frame to offer your customer, in particular on thebasis of what is already scheduled nearby or far.
   
   Moreover, if from within this context you click on the item-locate indicator within DispatchMap, you may select a time-frame. Upon such selection, ServiceDesk inserts the corresponding appointment back into the Callsheet (if in fact it's a Callsheet you linked from), or, if it was instead a JobRecord, it opens the ScheduleList interface with appointment entry poised for saving, as connected to that JobRecord.
   ‍

2. From either of the same contexts, you may right-click in an applicable city/state/zipcode box, to have the system invoke the Zone-Locate function within the ZonePlanner. What this does, is to highlight the particular zone that's involved, allowing you to visually zero-in on and discern what is the availability status within that zone. Especially as you page-up or page-down to examine various days, you can quickly determine which days still have vacancy for that zone.
   
   Moreover, much as is true in regard to the Item-Locate feature in the DispatchMap, here you can insert a selected day back to the calling context (i.e., Callsheet or ScheduleList entry as associated with a JobRecord). In this context there is a separate button for the purpose (up near the interface's top-right corner) or you can simply hit Enter on your keyboard when displaying the day whose date you wish to have inserted back.
   ‍

3. With this present addition, it is now also true that, from either of the same contexts (i.e., Callsheet or JobRecord) you may right-click in an applicable customer-name box, to have the system invoke Target-Specific mode in your DayPlanner interface.
   
   Moreover, just as you may from the other two contexts cause insertion back of a chosen appointment date, you may from this new one as well. Here it's done by clicking on the header that's at the top of the date column whose date you wish to insert. If you float your mousepointer over the black header that contains dates at the top of each date column (and when in Target-Specific mode), you'll see ToolTip appear, which reminds of this method.

With this broad outline under our belts (regarding what are now three parallel, albeit different-method functions), you may find yourself wondering what is special about "Target-Specific" mode in this new context?

First, by way of contrast, Item-Locate to the DispatchMap shows you a job's geographic location vis-a-vis other appointments. Zone-Locate via the ZoneScheduler gives you focus on availability as applicable to the particular zone that's involved.

Target-Specific view, in the DayPlanner, does a whole other thing.

Specifically, if you have created associations between technicians and zones (see here), it will filter to show in its display only those technicians (and their appointments, naturally) that are associated with the zone involved. Additionally, if you are using a skills matrix (see here) and either: (a) it is a JobRecord with designated skills; or (b) if it is a Callsheet with indicated machine type in the appropriate box, and if you have associated machine types with skills (see here) -- if those elements are present, the DayPlanner's Target-Specific mode will filter to show just those techs who are listed as possessing such skills as are (by logic of your setup) required for the appointment. If both filter bases are applicable, it will filter for both accordingly.

Whenever it displays in Target-Specific mode, the left-hand column of the DayPlanner (which contains technician names) will display in a non-white color to visually indicate: (a) that in fact you're in Target-Specific mode, and (B) what kind of filtering is presently applicable (grey for zone-based, yellow for skills based, green for both, and red for no filtering at all). In fact, you may float your mousepointer over the colored column to see a ToolTip which explains the precise filtering basis that is applicable. Also, you may click on any tech's name in that column for a display of applicable Technician Properties, much as is available via other contexts (see here).

You may think of this feature as still a further step in our expanding modes of "Guided Tech Selection" (see here).

As another parallel with the DispatchMap (though the methods are slightly different), you may click on any appointment reference to instantly see the underlying JobRecord, or may shift-click to instantly see the underlying ScheduleList entry (and edit there, if wanted). A ToolTip reminds you of this with appropriate mousepointer floating.

If you're a smaller user, it's likely this section and the following will be of little interest to you, and you can skip both. If you're a larger user (perhaps 25 techs or more), you'll likely find that the described new tools offer you significantly enhanced power, convenience and efficiency. We do think it's important, in order to promote full context of understanding, to layout some background as to where and how these new features fit in.

On 3/20/18 we introduced an option whereby you may specify that particular techs are intended for assignment to particular zones (see here).  Simultaneously, we made it so, if you’ve used that option (and as an early form of “Guided-Tech-Selection,” see here), ServiceDesk will lead you to select from only among potentially applicable techs when in the Job/Sale transition interface.  

On 7/31/20, we introduced ability to create a skills matrix, and to indicate which jobs need particular skills, and which tech possess those skills (see here). Initially, this was only for use in the also recently-introduced GraphHopper-based Whole-Roster-Optimization (see here).  

But then, on 8/10/20, we brought all the above together in a robust Guided-Tech-Selection functionality (see here).

Separate from the above, on 9/1/20 we introduced an option whereby you may create Department-Specific-Zones (see here). But there was little in the way of added elaboration on this. In particular, we left it entirely up to user initiative to pick a department that is applicable to the type of machine being serviced.  

The above-described absence of elaboration is significant, because the Department-Specific-Zone feature was added as a way to manage availability of technician resources while simultaneously dealing with crew compliments that are setup for servicing different categories of merchandise. As an example, suppose that in a particular region I have two furniture techs and five appliance techs. If I define that region as a single zone with the availability of seven techs, it’s possible I’ll get more furniture jobs than my furniture techs can handle, and vice versa.  

Anyway, as valuable an addition as that feature may be for coping with the described circumstance, we again left it to the user to pick, where applicable, the particularly-needed Department (from which point ServiceDesk would then, in itself, pick the needed Department-Specific-Zone).  

At least this is what would happen when you went through the Job/Sale transition from a Callsheet (which, of course, is where an applicable Department is user-selected). This would not occur until then, which means when you pick a street in a Callsheet, it would be a non-Department-Specific zone that would be inserted. This was not necessarily a terrible issue, but was not ideal.  

In particular (and among other matters), if you were using the Zone-Locate function from a Callsheet, and for the purpose of seeing availability for an applicable zone to aid in scheduling, this could lead (for that particular context) to examination of other than the correctly needed zone. And, now that we’ve added the DayLocate feature to our new DayPlanner interface (see here), that limitation creates a parallel problem, in this case residing in this new interface (a difference in this new interface is that, absent the solution which we now describe, it would potentially filter for such techs as work in a different zone than the correctly-needed zone).  

Our solution to all of this is a new “relationships” file called WhchMchnToWhchDept.CSV.  

Like a few other relationship files, this one will contain two columns. In the first column and on each line, you’ll place a machine type description, verbatim, just as it exists in your ServiceDesk dropdown list of Types. In the second, you will place, verbatim from your list of Departments, whatever Department it is that you wish to have associated with that machine type.  As with similar files, you’ll save this (and in comma-delimited format) to the \sd\Netdata folder on your server.  

On basis of seeing this file present, ServiceDesk will do several things.  

1. When in a Callsheet you’re entering an address and pick a street from the dropdown, ServiceDesk will look to see if a machine type has already been entered in that box of the Callsheet. If yes, it will look in this file to see if a department is associated with that machine type. If yes, it will, in assigning a zone into the Callsheet, look to see if there is a zone that is specific to that department. If yes, that’s the one it will insert.
   ‍

2. Even if a machine type was not already selected as per description above (i.e., you’ve done the street insertion before selecting a machine type), if you go into the type description box and select a Type, the system will then do a look identical to as above described, and, if a different zone is found as applicable as the machine type inserted, it will replace the zone indication accordingly.
   ‍

3. When you do the Job/Sale transition, ServiceDesk will look to see if the Callsheet-indicated machine-type is listed, in this new file, with an associated Department. If yes, it will auto-select that Department for you, within the Create Job/Sale interface.

Based on the above, if in fact you are using Departmentalization and in a manner that different departments fit for different categories of machine types, you can be assured (based on #3 above) that a correct department is consistently selected, and with reduced user effort. Perhaps more importantly (based on #1 and #2 above, and if you’re using Department-Specific zones), you can be assured that, even from a Callsheet, the Zone-Locate and Day-Locate functions correctly point you toward seeing correctly-targeted availability.

You may note that Department-Specific Zones invoke sort of an alternate method for managing the connection between what jobs require and which personnel are capable of meeting those requirements (i.e., as opposed to by having explicitly-defined skills, along with indicating which skills are possessed by each tech and which skills are required on each job, see here).  

Depending on your needs and preferences, you might decide to use one method or the other, or perhaps even a combination of the two. Regardless, if you’re using explicitly-defined skills, we’ve now made it so you can get added assistance in such regard, and of a kind that significantly parallels what’s described above for Department-Specific Zones.  

This is done via another new file that you may optionally create, this one called WhchMchnToWhchSkills.CSV.

As with other such files, you should create this in Excel or similar, and use two columns.  In the first column, and on each line, place a machine type description, verbatim, just as it exists in your ServiceDesk dropdown list of Types. In the second, place a numeric indicator for any such skill or skills that you wish to have auto-associated with that machine type (if multiples, separate each by a  comma, much as it’s done in your TechnicianExtraSpecs.csv file, see here). As with similar files, you’ll save this one in comma-delimited format to the \sd\Netdata folder on your server.  

On basis of seeing that file present, ServiceDesk will do two things.  

1. When from a Callsheet you use the new Target-Specific-to-DayPlanner feature (see here), it will look in this file to see if the indicated machine type is listed and with one or more indicated associated skill requirements. If yes, it will filter in the DayPlanner interface to show only such techs as you’ve indicated (in your TechnicianExtraSpecs.csv file, see here) possess the indicated-as-required skill(s).
   ‍

2. When you do the Job/Sale transition, ServiceDesk will similarly look to see if the indicated machine-type is listed wish associated skill requirements. If yes, it will auto-select such Requirements for you, within the Create Job/Sale interface.

The impetus for this came from a California client (thank you Heather at J&M) who reported on need to monitor what total sales are, at given points within a month, to an electrical utility that frequently orders service, but needs to keep its monthly expenditure on such service within a within a particular maximum.

How it works is, from within the QuickEntryTemplates interface (Shift-F1 is the shortcut), click on any listing to select it, then click on the new button shown here:

A dialog will inquire as to wanted date range, defaulting with such dates as will inquire on sales-to-date for the current month. Then, a simple message box will provide simple tally information:

In regard to its parts management (and though with some exception), ServiceDesk has generally assumed that tech's acquire and/or return company-managed parts (whether s/o or stocking inventory) to the "OF" (i.e., Office) location. However, some companies manage separate sets of techs in disparate locations, and have different parts-managing warehouses convenient to each. For such operations, ServiceDesk's general assumption of "OF" has not been a good fit.

Now you can change that assumption (and for whatever such techs as are applicable) to whatever defined inventory location wish for it to be.

It's done in the Technician Properties section of the Settings form (hit Ctrl-F1 then click on the desired tech's name), as seen here:

Just put in the two-letter code for a defined inventory location other than OF, and ServiceDesk will then assume that is the location from which the tech is obtaining from and/or returning to office-managed parts.

It's long been true that in each tech's Technician-Properties window (hit Ctrl-F1 then click on the desired tech's name), you may select to indicate whether he begins each day's route at his home or your office, and at which of the two he ends. This has been for use in the Google-based single-route-optimization feature, which is likewise a long-standing offering.

On introducing the GraphHopper-based Whole-Roster-Optimization, we learned that some users need to indicate start and end locations for some techs that are neither home or office locations. So, we made an option to so specify, as described here.

The thing is, even if you setup for use of the option above-described, it only worked in the GraphHopper-based Whole-Roster-Optimization, and did not apply in the more simple Google-based, single-route optimization.

Until now.

Now, if you in fact so setup, the alternate-defined start and end nodes will supersede, for Google-based single-route-optimization, vis-a-vis what is otherwise set in a tech's applicable Technician-Properties window.

This entry will be of interest only if you use this supplementary application. If otherwise, you should disregard.

The first new enhancement involves a much improved sales-report. Here we're talking specifically about sales of serialized merchandise, as opposed to service and parts.

This particular report is accessed via a somewhat funny path. If, within the SD-Dealer, you click on "Reports" button and then choose "L", you'll see the report is actually produced within ServiceDesk by going to it Reports form (F11), and then using the keyboard combo Shift-Ctrl-Alt/M (yes, it's kind of hidden; the reason is because most SD users do not also use SD-Dealer). Besides now being formatted, the report is now also equipped to indicate what was your sell-for price on each machine sold, and what was was the margin.

This improvement requires that you also update to the current SD-Dealer release (Ver. 1.0.59) or higher. Said update is required because, among other things, the new release creates new database fields that keep track of such sell-for information.  Further changes in ServiceDesk make it so, when you do a sale (and as manged iva ServiceDesk's POS), applicable new fields are populated with sell-for price - at least when possible.  In fact, when you a do a sale that leaves identification of the particular unit to later, it instead populates to the same table that keeps track for that purpose.  If the delivery is managed via SD-Mobile (and it's identified via that path which instance of a model was actually sold) then SD-MobileLink (on processing the applicable PVR) populate precise applicable record accordingly.  For this purpose, you also need to updated to SD-MobileLink Ver. 2.0.124 or higher.

Because this discrete sell-for-price info has not prior been being recorded as such, sales that you conducted before these updates will not on their own be instantiated with such values. If you wanted to to, however, you could go back and manually insert such values. You'd need to open the \sd\NetData\UnitInfo.mdb database file in MS Access, then double-click on the DlrInvntry table to open it for editing.  You could sort on the ItemWasSold field to segregate items sold from those still in inventory.  In each/any line item, you could then manually fill-in the applicable SellForPrice.  

The second new enhancement relates to the longstanding feature you may select a set of items from the main/primary listing of merchandise, in SD-Dealer. If you then hit Ctrl/P (a standard keyboard shortcut for printing), SD-Dealer offers  to print a detailed listing describing the items selected, with pricing total, and so on.  Now, the same action let's you choose, alternatively, to send this detailed listing to an Excel file, or similar.