The SD-WorkDiary Improvements in ServiceDesk are fast and furious. Not all releases are announced here (many involve mere incremental tweaks and fixes). This blog mentions only releases that involve significant enhancements. It's so you can know about and take advantage of them. New entries are placed at top, so reading downward takes you back in time (like digging ever deeper at an archeological site). To initiate a textual search, hit Ctrl-F on your keyboard. |
New Rossware Website: rossware.com:
Many months ago, we finally "bit the bullet" and paid the ransom for the domain name "rossware.com" (it had been long held by persons that claim title to a domain name in the hope of making big bucks by selling it to the party that really wants it). In the meantime, our newest resident genius, Alex, was at work building an entirely new Rossware (and terrifically modernized) website.
That new website is now published under the rossware.com domain name (specifically, the url for it is https://rossware.com, but if you merely type "rossware.com in your web browser's address bar, it will take you there).
Pretty soon, we'll re-direct this website url (http://rossware.net) to the new rossware.com.
In the meantime, we are no longer actively making new SD-WorkDiary entries in this old venue. Instead, all new entries are going exclusively to the SD-WorkDiary that's present in the new site.
Please click here to be linked to that new and current SD-WorkDiary.
THIS IS THE LAST ENTRY HERE !!!!!!!!!!!!
Barcode-Scanner Enabled Check-Offs in the PartsPick Form:
This is another item for which we must credit Tony Tyrell in Maryland.
Tony runs a big operation. His people have a ton of mouse-clicking to do, within the PartsPick form, as they click to indicate a particular expected item is being placed in the tote to go outward to a tech, and or as they click to indicate another particular item has appropriately come back from him.
They have so many items that, even though simple mouse clicks are quick and easy, the time consumption overall can still be quite large.
Even worse, because they are going through so many items, errors happen all too frequently. As an example, it's pretty easy to click on a wrong item to indicate -- and perhaps erroneously -- that it's been moved to or from the tech.
Tony wanted a method that would be both faster and more accurate.
Accordingly, if you look in the PartsPick form (shortcut is Shift-Ctrl/F8) when running with this new release, you'll see three new little squares:
If you float your mousepointer over any of the three, you'll see a Tooltip appears, to inform you of the purpose in those little squares.
The purpose, simply, is you may click on any such little square to toggle its list section into barcode-scanner mode. And, when you do, you'll see a bit of visual transformation, as shown here:
The purpose of this transformation is to make it visually obvious that the applicable list section is in "active mode" to receive barcode-scanner input.
Thus, if (with a list section in that mode) you "zap" a part-number-containing barcode, ServiceDesk will instantly look within the list for matching part number. Upon finding a match, it will instantly react just the same as if that item had been mouse-clicked.
Based on this, we think it should now be super fast and accurate to move items to and fro, between your central location and your techs.
. . .
As a BTW, if you're interested in acquiring one or more wireless barcode scanners, we recently acquired this Bluetooth one, and find it quite nice ($50 at full retail, but if you find it on sale it can be cheaper).
New "With-Barcodes" Printing Option:
In the same PartsPick form as above discussed, there has long been an option to print any particular technician's "PartsPick" list. Now, when you choose to print and are presented with the "Select Printer" dialog box, you'll see there is a new option checkbox that, if checked, will cause the printout to include barcodes:
New Filters in JobsPerusal Form:
If you did not know, the keyboard shortcut for this form is Shift-F7. This interface is used when you want to review pending jobs that fit within any of several particular categories (e.g., waiting for parts, needing to be scheduled, etc.). As time goes by, we continue to receive requests from clients for new bases by which to "filter" the particular set of jobs that are shown. Recently, we accepted two new requests.
First, while the JobsPerusal form has long had ability to show only such jobs as are most-recently associated with a particular technician, it has not had ability to show only such jobs as have no association with any tech at all. So, that's the first new filtering option that is now added:
Second, there is now a filter for Wants Sooner:
For context, several years ago we added a colored toggle box to the appointment sections (applicable in both Callsheets and JobRecords) which you can toggle to red to indicate the customer wants the appointment changed to a sooner date, should opportunity arise within your schedule. Here is the toggle box:
Simultaneously, we added a function in the DispatchMap where you can display the locations of each pending appointment (regardless of whether the appointment is for the displayed date) that is toggled for Wants Sooner. By this means, you can look at any particular day where capacity has opened up, and see what Wants-Sooner appointments are convenient to where techs are already driving.
Regardless of that existing capability, a particular user thought it would be nice to be able to also review Wants-Sooner requests from the perspective of the JobsPerusal form, so that capacity is likewise now added.
New "Inventory Import" Feature:
I am not sure why this happens, but from time to time we are contacted by a client who, having decided to finally to begin using ServiceDesk's inventory control system (it's a function that many users initially put off), began in the effort by laboriously entering all of their inventory into an Excel spreadsheet. I don't think this path generally makes sense because, absent certain narrow exceptions, it's far easier to enter inventory directly into ServiceDesk from the get go.
Regardless, if you have basic and reasonably accurate inventory data in an Excel spreadsheet, you naturally hope for a way by which to import it into ServiceDesk's inventory system. Prior to now, there was no mechanism in ServiceDesk by which to do this. It's somewhat of a complicated matter, because everyone ends up arranging inventory data in their spreadsheets differently. So, when contacted by a client wanting to import such data, I have in each instance written custom program code, tailored for the particular data as arranged in the client's spreadsheet. There was also in each instance a fee for this custom work.
Well . . . that's not needed anymore.
I've created a system that allows you to describe how the data is laid out within your Excel spreadsheet and -- on the basis of your description -- ServiceDesk will perfectly import that data for you.
By way of disclaimer, I have not invested so much as would be needed to make this system as beautiful as it could be. In particular, an optimal method for describing the layout of your spreadsheet data would involve an interface where you can point to actual columns from your spreadsheet and tell ServiceDesk (simply by picking from a dropdown in regard to each such column): "Okay, this column contains part numbers; this column contains descriptions; this one indicates what we paid for each part, etc." Instead of investing to make that kind of more optimum interface, I've taken a shortcut via which you provide ServiceDesk with needed details via a back-and-forth dialog (e.g., it asks which column number contains part numbers, and you answer).
Regardless, it works. The method for invoking the dialog (and of course for proceeding with an actual import as the dialog completes) is to use the keyboard shortcut Ctrl-I from within your F10 Inventory Control form (the "I" is for Import).
FYI, the import is designed to add to whatever such Inventory and MasterPlan data as already exists in your system. For such reason, if you want it to replace existing Inventory and/or MasterPlan data, you should delete applicable files first (our support team can of course assist).
Technician-Specific Settings Now Available for Controlling Technician Duties and Rights in SD-Mobile:
A reader may think this entry should be in the SD-Mobile WorkDiary, since it directly pertains to that system. However, ServiceDesk is in fact the place where these new settings capabilities will be managed, so it makes very good sense to describe the new wherewithal here (don't worry; we'll also mention it in the SD-Mobile WorkDiary).
For context, over the years the SD-Mobile system has accumulated a plethora of options whereby a manager may, according to preference, specify a bunch of different elements of interaction that govern what the company's techs can and/or must do within the Mobile environment. These options are all set from within a particular section of the SD-MobileLink program, as shown here:
A particular thing to note about such settings as shown above is that whatever is set by the manager is going to apply to each and every technician in the company. There is no ability, for example, to turn on PVR enforcement for one or more technicians that particularly need it, while leaving that disciplinary feature turned off for technicians that need no such discipline.
Now we have changed that.
In particular, please go into the ServiceDesk Settings form (Ctrl-F1 is the shortcut) and click on any particular technician's name (within the roster of technicians) so as to expose that tech's Properties window. Upon so doing, you'll see there is a new button in the section of the Properties window that pertains to SD-Mobile usage:
Now, please click on the new button as shown above, and you'll see this new interface:
As you can see, the main body in this new interface looks very much like that section as above shown from within SD-MobileLink, and you have the option, in regard to any particular tech, of deferring to such general settings as are there specified, or to set specially and specifically for the selected technician (if you switch to that option, all "borrowed-from-SD-MobileLink" options become enabled so that you can set per specific preference).
If you're wondering, yes, if set with the first option this interface will display with such settings as you have specified in SD-MobileLink. If changing to set specially for a particular tech, it will first show with those same settings, and you can change from there as desired.
Caveats:
If your settings in SD-MobileLink are other than original/standard default, the "defer-to-standard" mode in this new interface will not show your particular general settings until and unless you have updated SD-MobileLink to Ver. 2.0.86 or above, and allowed it to cycle at least once (otherwise it will show original/standard defaults).
You must likewise have your SD-MobileLink updated to Ver. 2.0.86 or above in order for it to see any such particular-to-tech settings as you have created, and for it to port this information outward to each involved tech's system.
For techs using the Windows version of SD-Mobile (aka SDM-w), they must be updated to Ver. 2.1.8 or above (older versions are not coded to get and use the new and specialized information).
For techs using the iOS version of SD-Mobile (aka SDM-i), we are still working to upgrade some background processes that will enable their interfaces to get and use the new information (ETA on that is later this week).
Gender Neutrality:
Are all of your technicians male?
If yes, this will not have been a concern for you.
To be sure, right within this WorkDiary, I often use male pronouns when referring to technicians. It's easy that way, and it fits, likely, 99 percent of the time.
But not all of the time.
Fred's Appliance in Ohio happens to employ an excellent female technician. Adam (from Fred's ) pointed out to me how certain language in the appointment confirmation process comes across very poorly for appointments that are scheduled for this female tech, especially where Fred's has configured so that their confirmation-request emails include a picture of the assigned technician, and in this case the picture very obviously shows a woman. Imagine seeing such a picture, with text just below such as:
"We estimate he'll be arriving . . ."
and
"He's scheduled to work on the following . . ."
Imagine the customer clicks on the link to confirm, in the resulting online interface does confirm, and in response receives an automated email that includes:
"We appreciate you confirming your appointment. It allows us to dispatch the technician with increased confidence that when he arrives at your doorstep, there will be a successful connection."
To address this issue, we've added a new field that may be used in configuring this text. The default text has already been configured to use the new field. If you're using customized text, you can update your customized text to use it as well (yes, the customizing-text manual has also been updated to show potential use of the new field).
The new field references, simply, the applicable technician's first name, and allows for a change from such examples as shown above to the following instead:
"We estimate Corina will be arriving . . ."
and
"Corina is expecting to work on the following . . ."
Besides the fact this change avoids the gender pronoun difficulty, I like that it also makes the language more direct and personal.
In regard to the email that's sent by SD-CyberLink after the customer completes confirmation, applicable language there has simply been changed from what's shown above to this instead:
"We appreciate you confirming your appointment. It allow us to dispatch the technician with increased confidence that, when arriving at your doorstep, a successful connection will be made."
This change in the SD-CyberOffice-sent email will require updating to its Ver. 4.5.62 or above.
Update Grid Reference Tool Available in Current-JobRecords Form:
If, in a current-JobRecord form (F7 is the shortuct), you do a Ctrl/Right-Click within a customer's address box, you will now see something new.
Specifically, you will see the StreetList dropdown appear, similar to when you are typing a street name into a Callsheet.
We made this function to make transition easier whenever a user updates to a re-designed map wherein the old grid system is no longer controlling, and, thus, presently in-use references need to be changed so as to match the new system. It might be useful in a few other contexts, as well.
When you pick the applicable street from the dropdown, the system will insert its coordinates. Simultaneously, it will look for any pending appointments, and offer to update such coordinates as attached to them, as well.
EMV-Compatible Credit Card Processing -- In Other Words, You May Now Use "Chip Readers":
Rossware has done the coding and been certified for its Windows-based Virtual Terminal to work via Cayan's Genius Mini.
The "Mini" is a beautiful little cordless device (connects via Bluetooth) which can easily fit in a tech's pocket or be carried on a neck lanyard. Besides allowing card insertion for chip reading, it also allows a traditional swipe. Even better , it allows NFC proximity reading (i.e., reading via card taps, for any card that is so configured).
Also, the device is inexpensive (only $59 per unit).
The one drawback is that Cayan imposes a monthly $9.95 fee on use of the device. That's potentially offset by the fact that, by switching to the Genius system, you may eliminate your annual PCI compliance fee.
Here are instructions for switching into use of this device:
Acquire a device for
each person/place you want it to be used.
Work with Cayan to
assure your Cayan gateway profile is on the platform which allows
EMV processing (it's a particular "First Data" platform, I believe).
Assure each person
is operating in a version of SD or SDM that's been updated to use
the device (all Window's-system releases from 4/19/18 onward have
the capability; SDM-i is likely still a month away).
For use in Windows
platforms, you'll need to download and install the Genius
Application (this application works as an agent that is called
to do certain processing by Rossware's Virtual Terminal; if you have
not otherwise installed it, the Virtual Terminal will prompt you and
provide a link).
From within the
Virtual Terminal interface, click on the "Device Setup" button, and
select as shown here:
With the above done, you should be able to run
perfect transactions using the Mini in any of its modes.
New Option for Sending a StartOfJob Communique When Creating New Jobs:
In June of last year (see item several entries below pertaining to Rel. 4.8.29) we enabled User-defined Email- and SMS-Templates (in a nutshell, you can create and contextually deploy your own "form-letter" setups for emailing or SMS-messaging your customers).
Recently, Matt Parker suggested a context where you might want to use a special-purpose such template. That purpose is where you have first scheduled a new job with a customer. Perhaps you want to send an email thanking the customer, advising of general policies and what to expect, etc.
It seemed like a great idea.
To make it effective, we obviously needed something more than to simply rely on a CSR to volitionally think of sending such a missive in each instance. We needing for the sending to be more automated, and definite.
Matt's idea was to optionally incorporate this sending event right into SD's Job/Sale transition. So, that's what we've done, via a new option as seen here:
As you can see, we are calling our new and special kind of missive the "StartOfJob Communique." The option to pick its use is (or, at least, we think it should be) self-evident.
Regardless, I'll explain.
Assuming you leave that new box checked, ServiceDesk will automatically send (in conjunction with job-creation) the particular User-defined Template that you have designated for this purpose.
Please note this new option will automatically activate and insert a checkmark if in a suitable situation (e.g., the Callsheet that you're transitioning from is setup for COD work and includes a consumer email address, plus you have setup your system overall with a suitable template for the COD situation). Thus, the default for any applicable situation is "on," and it's only by deliberate user action (un-checking that box) that sending will not be inclusive to the Job/Sale transition.
In regard to designation of a template for this purpose, it's done by the title you give to the underlying file that contains the template, and you can in fact designate two different templates: one for COD jobs and one for third-party-payer jobs (presumably, suitable language is different for those different situations). Complete instructions have been added as the last page in our User-Defined-Templates Handbook.
Assistance for Assigning Technician in Multiple-Zone Situations:
If you have a larger operation and it covers a significantly large territory, odds are good that you use the ZoneScheduler system to divide your area into separate zones, and that you have particular techs working within particular zones.
If the above is true, you'll be interested in this new feature.
In a nutshell, you may now indicate which techs you wish to have associated with which zones, and the system will use that information to limit the list of suggested technicians for assignment to an appointment during the Job/Sale transition from a Callsheet.
To use this new system, you need to create a very simple file. It's probably easiest if you use Excel or similar to create the file. The file needs to have one line item for each of your zones, and just two columns in each line. In the first column you should place the zone number that is applicable to that line. In the second column, you should simply list the two-character abbreviation for each tech that you wish to have associated with that zone (and with each separated by a comma). Thus, it might look something like this:
Please note there is no reason why any particular tech cannot be associated with more than one zone (depending on your situation, this may indeed in many cases be very apt).
This file must be saved in .CSV format (that extension specifies a structure that is comma-delimited), saved with the precise filename WhchTechToWhchZone.CSV, and placed into the same sd\Netdata folder that contains your other primary ServiceDesk data.
What happens is, when you engage in the Job/Sale transition from a Callsheet, the system looks for presence (or not) of the above-described file. If it's there, and if there is a zone assigned to the new job, the system looks in that file for a line that has the applicable zone indicator in its first column. Upon finding such a line, it looks in the second column for an indication of associated technicians. Upon finding those (and verifying that each is a currently valid tecnician), it places each in the dropdown from which you may select, for assignment to the new appointment.
In other words, instead of seeing the full list of technicians, like this:
You'll see a list that's limited to just the zone-associated technicians, like this:
Please note we've configured so there is a different background color in this dropdown list, depending on if it has been populated on a limited-to-zone-associated-techs basis, or if it's a more traditional showing of your entire roster of techs (rose-colored for the new/optional mode, blue-colored for traditional).
Please note further if you float your mousepointer over the dropdown listing in either mode, the system will display a ToolTip that describes the mode and suggests how you may toggle to the opposite mode, if desired . . . as seen for one mode here:
Assuming that this is something you want, please don't be intimidated by the need to setup the underlying file. It's really super easy, and our support staff will be delighted to assist, if you wish.
Designation of "Pseudo" Appointment Via the Job/Sale Transition:
To remind, in ServiceDesk we have real appointments, pseudo appointments and fake appointments. The meaning of a real appointment is obvious. A pseudo appointment is for a real customer and is attached to a real JobRecord, but the tech is not expected to actually go to the customer's home (instead, he's expected to do some element of follow-through on the job, during the allotted appointment time). A fake appointment, on the other hand, is not in any manner attached to a customer or JobRecord. It might be for something, as an example, like "Get an oil change."
Until now, designation of an appointment into pseudo status was done from the F6 ScheduleList form, by there unchecking the little checkbox that otherwise is by default checked to indicate the appointment is real. A particular client wanted ability to make that designation when an appointment is created simultaneous with Job/Sale transition from a Callsheet, so that now exists, as seen here:
Absent this new option (if for whatever reason you wanted that initial appointment to be classified as pseudo), you would have had to go into the F6 form after the Job/Sale transition, to there uncheck the checkbox. Now you don't have to do that.
You Control Quantity of Days for Warning re Recent Prior Work on Same Machine:
If you check the last entry in the posting just below (i.e., the posting that concerns release of Ver. 4.8.51), you'll see where we describe a new feature, where a user will be warned, when doing a Job/Sale transition, if there was a prior job completed on the same machine Type and at the same address, less than 60 days prior.
Of course, that 60-day warning period did not suit everyone.
So, we've made it so you can set the warning period to preference (it will still default at 60 days).
To do so, bring up your Callsheet "Cheat-Sheet" (just right click on any otherwise non-operable place on the face of a Callsheet). Look for the following in the resulting Cheat-Sheet display, and click on it:
When you click on that item, you'll be presented with a dialog that allows you to set the warning period to a quantity of days other than 60.
For Improved Speed and Performance, Automated Segmentation of Files as Contained in the HLinks Folder:
If you did not know, any drag-and-drop hyperlinks that you create are stored in your \sd\HLinks folder. A few other kinds of hyperlinked files may be stored there as well. Over time, you may accumulate a large quantity of files there. This may be a problem because Windows is sometimes extremely slow when accessing contents within a folder that contains too many files. In consequence, if you're wanting to open a hyperlink in ServiceDesk (or create a new one), you may find there is an atrocious delay.
Obviously, delay is bad!
The simple solution is to distribute any such large quantity of files, as may presently exist at the root level of your \sd\HLinks folder, into a set of subfolders, with each containing a more manageable quantity of files. Believe it or not, this fully solves the issue. However, you may not think to do it, you may not know how to do it, and you may not want to be involved in such work.
We have a solution.
Now, ServiceDesk watches to see how long it takes when Windows is asked to access contents within your HLinks folder. If it detects Windows taking more than a second, it will inform you that is too long, and will offer to run a routine that will automatically go through all those files in your HLinks folder, parceling each into a subfolder that corresponds with the month in which it was created.
Thus, instead of having, say, 60,000-plus files in the root-level of \sd\HLinks, you'll end up with a bunch of subfolders, each containing a much smaller quantity of files. This enables Windows to do the needed file access, without being slow.
You may also, if you wish, access this new function directly, as shown here:
Catch the TimeCard Scoundrel:
I received a call from a particular client. He has a CSR who is terrific in almost every way, except this person routinely arrives late (often, many minutes late). Curiously, this person's ServiceDesk TimeCard nevertheless shows her as, supposedly, always arriving on time.
How can this be?
Our client's suspicion is that this otherwise terrific CSR is just crafty enough to reset her computer's system clock (to falsely indicate correctly-expected arrival time) before "punching in," then she resets it back to the correct time afterwards.
Aside from admiring the cleverness (while perhaps also despairing over the fiendishness), how do you catch that?
In answer, we have created an added element of behind-the-scenes management, as a person uses ServiceDesk to punch in or out. Essentially, the system simultaneously does a little query via the internet, asking an external time source what is the true and honest time. If the true and honest time is more than three minutes different from the time on the computer's system clock, ServiceDesk writes to a secret file, providing details on the event.
We are not going to indicate here what is the name or location of that secret file. After all, if an employee that wants to engage in this practice knew where to find the file, he or she might open and edit it to hide the evidence. Assuming that, as an owner or top-level manager, you wish to make use of this file, please contact our support team (email support@rossware.net, call or open a support connection), identify yourself as a person in an authorized role, and we'll provide instructions on how to locate the file. We do not want to provide such information to mere employees.
Automated Alert
If Having Worked on Same Machine Within 60 Days:
The concern is as follows:
You've received a request to perform service on a machine. The person who is doing the Job/Sale transition fails to realize that prior work was done less than 60 days ago. If that fact was realized, there are certain things that would have been done differently, in setting up the job. Because it was not realized, those things are not done differently.
Now, ServiceDesk watches for you.
When the Job/Sale button is activated from a Callsheet, ServiceDesk looks to see if there was a same-address and same-Type-Description job, completed less than 60 day prior. If so, there will be a little popup like this:
Response by the user is obvious.
Zone Identifier Now
In PartsLabels as Applicable to S/O Parts:
Speaks for itself, I think.
Auto-Dialing and Caller-ID, Turn-Key Integration with Service Company Solutions Telephony Systems:
Service Company Solutions (SCS) is the same company that brings you "The Blue Book." Over the years, this company has developed many superb supplemental systems that are targeted, primarily, toward assisting appliance repair companies. A relative newcomer, in their array of services, is provisioning and support of complete and robust telephone systems.
This is good because, obviously, Rossware clients need good telephone systems.
More fully, Rossware clients would like to have telephone systems wherein it is very easy to do direct integration.
One purpose of such integration is auto-dialing. Put simply, you see a telephone number in ServiceDesk and want to dial it. Just click, and the dialing is done for you. It's beautiful.
Another purpose is Caller-ID.
The phone rings.
Maybe you'd like to know real stuff about the caller before picking up the line (e.g., the circumstance of any job or jobs that may be pending for that person, any history of past jobs, etc.). Maybe you'd like to simply use the Caller-ID number and name as basis to easily and accurately insert into a Callsheet.
Integration with Caller-ID makes all the above into reality.
As the phone rings (and if in ServiceDesk it is the first vacant Callsheet that is selected or turned to), ServiceDesk will place the caller's telephone number into a little window next to the Callsheet's first telephone number box. All you must do is click on that little window, and the number inserts for you. Besides the fact this accurately places the number into the box, it simultaneously triggers a search in your ServiceDesk Customer Database on that telephone number. Thus, you'll instantly see references to all such present and past jobs as had any involvement with that telephone number.
Similarly, ServiceDesk will place the caller's name into a little window next to the Callsheet's CustomerName box. All you must do is click in that window, and, again, ServiceDesk will insert the contents into the Callsheet's adjoining box. This likewise triggers a relevant search in the Customer Database -- though in this case showing results based on the name, as opposed to on the telephone number.
Imagine picking up the phone and saying:
"Hello Mrs. Johnson. I bet you're calling about your washing machine repair. I see, in fact, we just get parts in for it, and we were about to call you."
Or, at the very least, being more prepared, than otherwise, to provide relevant and excellent assistance. Your customers will be very impressed.
Such functionality has been offered in ServiceDesk for a very long time. However (and sadly, we feel), most users have failed to take advantage. A large reason for this is that not all telephone systems can participate in such communication as is needed to make these integrations work. Even for those systems that in theory can so communicate, morevoer, it is sometimes precipitously challenging to complete the needed setup.
That's why this new cooperation is so great!
Working together, Rossware and SCS have configured elements on both sides so that, if you are a SCS telephone-system client, it becomes virtually a "piece of cake" to have full, perfect and robust auto-dialing and Caller-ID functionality within ServiceDesk.
It's a super-powerful thing, and now you can have it easily, along with getting into a wonderful telephone system to boot.
To learn more, your first step will be to explore with SCS what are the particular telephone system solutions they offer. Here is a link.
New Intelligence When Confirming Multiple Appointments that are Each Connected to the Same Customer, Appointment Date/Time and Assigned Tech:
We thank Tim Koyonen for pointing out the need for this improvement. He explained how it's pretty common for customers to request simultaneous repairs on more than one machine. Because the Mobile system is designed to connect to a single machine per JobRecord and appointment, the office will place each of a particular customer's machine requests into its own JobRecord, and make individual appointments as connected to each (all appointments targeted for the same date and time frame, but nevertheless each as its own individual record).
The issue that arises in this circumstance is, when requesting that the system send out appointment-reminder/confirmation-requests, it sends one request for each unique appointment and machine-to-be-serviced. Beyond the fact that your customer may be annoyed by these multiple requests, they may also be confused when they see the first request referencing one particular machine to be serviced, when knowing they requested work on that machine, and one or more others, too.
We've solved that.
With a combination of this ServiceDesk release and the current release of SD-CyberLink (Ver. 4.5.48), the system will be considerably smarter in handling this kind of situation. In particular, where you have multiple appointments, each connected to a different JobRecord, but each for the same customer, assigned to the same tech and for the same date and time frame -- where all that is true -- the system will note the fact and create a single reminder/confirmation-request to cover the entire set.
In fact, in each context where the reminder/confirmation process is poised to remind the customer of what kind of machine is being serviced, the system will intelligently create a combined description. Suppose, for example, there are appointments to service a Whirlpool Washer, a Maytag Range and a Kitchenaid Dishwasher. Formerly, there would have been individual descriptions for each (and each in its own particular reminder/request). Now, the single combined request will reference such objects of service in this manner:
"Washer, Range and Dishwasher"
Obviously, that's much more enlightening (and less confusing) to your customer.
Another benefit of this new intelligence is, when your customer confirms or cancels on the single combined request, the result flows back into each involved appointment and each involved JobRecord.
Please don't forget. You also have to update SD-CyberLink so as to enable this new intelligence.
New "Restore Defaults" Function in the Security Form:
The ServiceDesk Security form (Shift/F11) is, of course, where you indicate which actions are going to be password protected, which are not, whose passwords will unlock which door, and so on.
One challenge in regard to using this system is that, often, because new users don't have a good understanding of what's what, they end up somewhat foolishly putting locks on doors that don't really need them, and removing locks on doors that really should have them. We've structured the defaults (which doors initially have locks versus not) in a manner we think is optimum for most users. Where a user has, well, created something of a "which doors are locked and which are not" mess, it's possible they'll realize they just want to return to defaults, then adjust to particular preference (more carefully this time) from there.
Until now, we did not have a function for this. Now we do. When in the Security form you display Actions (this is the mode in which you see each door that may potentially possess a lock or not, and set each according to preference), a new little button appears, as shown here:
If you click on it, you'll get a dialog that asks if you truly wish to restore defaults. If you respond "Yes," that is of course exactly what happens.
Warning, in the Security Form, Against Locking Whole Buildings, While Simultaneously and Also Locking Doors Within:
At Rossware, we very much want for all our users to enjoy maximum ease, delight and smoothness-of-flow as they use our systems. Given this, we find ourselves feeling greatly frustrated when, as we're assisting on some issue, we see that a client must endure not just one, but two password challenges before they are permitted to display a particular report.
Why does that happen?
In a nutshell, we've structured the Security system to give you a lot of flexibility. In regard to the various reports that are available from within the Reports form, as an example, it's possible you don't want your employees, generally, to be able to access anything from within that area of functionality. If so, you can put a lock on access to the entire form (a lock that may be opened with authorized passwords, of course, but a lock nonetheless). Contrariwise, it's possible you don't mind if employees have access in this area generally, but there are one or two particular reports you consider sensitive, and do not want just anyone having access to. If so, you may forego having a lock on the context overall, while nevertheless putting locks on the particular individual reports that concern you.
So, we give you that flexibility, and . . . what happens in consequence?
Yes, many of you choose to put a lock on the entire context, and on individual reports within the context as well. Thus, there you are, having to endure one password challenge just to get into the context, then another to run a particular report within it.
Because we don't want you to be endlessly enduring this kind of unneeded and senseless frustration, there are now mechanisms to help keep you away (as you configure your Security settings) from making such a mistake.
In particular, where you choose to activate password protection in a whole-context area that also has potential password protections within (there are, incidentally, other such contexts, besides the Reports form), the system will look to see if you have activated password protection on one or more of the sub-areas. If so, it will suggest you should not have both layers, and will offer to delete one or the other. Conversely, where you are activating password protection on any potentially applicable sub-area, the system will look to see if whole-context password protection is activated in a manner that already covers that item. If so, it will again present a warning and similar options.
A Couple of New Password-Protection Options:
First, you may now password protect against editing a formerly-saved purchase invoice number in the PartsProcess (F8) form. Evidently, some users were finding that some of their employees sometimes inadvertently changed that number. This password protection defaults as turned on.
Second, you may now differentially distinguish, in password protection, between zone-overbooking that results from changing an existing appointment, as opposed to creating a completely new appointment. Formerly, a single password protection applied to either situation, but we found some people wanted a password challenge to exist for the new appointment situation, while not for a mere change. This addition allows you to so distinguish. It also defaults as turned on.
New "Systems-Sentry" Feature:
Many people have asked for this.
You've learned to rely on one or more automated systems. Maybe it's SD-MobileLink, which (assuming you are using the Mobile system) must be running to keep your techs updated with live information regarding work they are supposed to do. Maybe it's SD-CyberLink, which (assuming you are using SD-CyberOffice functions) must be running to provide live service to your customers who are seeking to book jobs online. Maybe it's SB-DispatchLink, which (assuming you wish to have live integration with ServiceBench) must be running to keep ServiceBench informed of your availability for scheduling, informed of the status of each job they have prior dispatched to you, and to download new dispatches they create for you.
It might be one or more of these utilities, or, potentially, any of several others. The point is, these systems need to be kept running, for, if they are not, needed communication processes will not be occurring in real time, as they need to occur.
In some instances a user at a station where such a utility is running may inadvertently close it. In others, the computer itself might shutdown. In still others, the utility might have encountered an issue that internally prevents it from continuing in performance of its work.
Regardless of cause, when any such utility is not doing its work, it's possible you, your employees and/or your customers might suffer frustration, prior to realizing and addressing the cause.
That's what this new system is designed to address.
In particular, it allows you to specify the systems that you are depending on and want to have watched. Based on that specification, it watches for you, and will proactively inform you if/when it detects that any such utility is not actively performing its work.
The heart of this new system is a new interface in ServiceDesk that we call the "Systems-Sentry" form. To access it, click on File Functions in the ServiceDesk Main Menu, as shown here, then on a new menu item:
This (or at least something rather similar) is what you will then see:
As you can see, the interface lists each of the automated-functions and/or separate utilities you might want to have monitored (an item will show in red if its box is checked and if the amount of time since its last cycle is excessive). You may simply check the box next to each/any item that you wish to have actively monitored. In the section immediately below the selection area, you may further indicate the method (or methods) that you wish for the system to use when alerting you.
If you choose to be alerted via a message dialog box within ServiceDesk itself, you'll see a message that looks similar to this:
If you choose to be alerted via an email, you'll receive an email that looks similar to this:
If you choose to be alerted via a text message, you'll receive a text that looks similar to this:
To be more precise, you'll receive such an alert if/when any item that's been activated for monitoring fails to show ongoing timely work. In particular, it will happen when a subject utility does not show active work for one hour or more, or when an activated and automated system in ServiceDesk (such as, for example, the Auto-Archive system) does not show active work for 24 hours or more.
Direct and auto-linked search into ARsRetired data:
Accounts Receivable records (aka A/Rs) records are not kept (at least they are not kept as such) after they are paid in full. The purpose of any such item is to show you have an outstanding expectation for payment. Thus, once such an item is satisfied, there is no longer any direct need for it. Regardless, it's nice to have a log that maintains information regarding such records as did exist, prior to their demise.
That is the purpose that has until now been behind-the-scenes served via an otherwise obscure file called ARsRetired.txt. The thing is, there has been no direct-provided access to the data in this file. When and if you encountered the odd-situation need for its information, you'd need to independently locate and open it, when search within its data for the item of your interest.
Now we've re-structured that file (it's now called ARsRetired.csv), and made its contents directly available from within ServiceDesk. In particular, in any action where you've requested to see any such A/R records as are connected with a particular job, the system will offer to further look into this data store. Thus (and as an example), you could receive information that an A/R record for Inv # 12345 was retired as fully paid on XYZ date, and with inclusion of such notes as existed in the record prior to its retirement, its total amount, etc.
Miscellaneous Improvements:
In the A/Rs Review form (F3), added ability to search on basis of A/R amount.
When you're composing an SMS text message in the SD-Mail interface, the system will now warn if you're approaching or exceeding the 160-character maximum.
Made it so pseudo-appointments now default to a JobCount value of zero (formerly they defaulted to a JobCount of 1, just as with standard appointments).
Made it so the Notes sections in the Rolodex (in particular, as applicable to Companies and Persons) will not automatically save user edits (the need arose because sometimes people were inadvertently making changes). Rather, the system will resist saving with any such change absent user confirmation that saving is wanted.
Made it so you won't be pestered about overbooking a zone pocket when editing an existing appointment, if that edit does not move the appointment to a different scheduling pocket, and if the pocket that it's in was already overburdened (formerly, any change in the timeframe would result in potentially being pestered).
Corrected the unintended (and formerly not known) fact that appointments as present in Hibernated Callsheets were not being counted against availability. Thanks to Paul Manning at Sharper Electronics for bringing this matter to our attention.
Powerful Hyperlinking Ability Now in SD-Mails:
This one is especially important for triage.
Slightly less than a month ago (scroll downward to see the third of "Four Very Big Items" in the 10/26/17 entry below) we announced our addition of a new online triage center. Part of the concept in this new interface is it's a piece of cake for anyone anywhere, when given appropriate credentials, to provide triaging service for you. Then of course the question arises, after someone has done needed triaging via that interface, how does the triaging information (that they've produced) get back into the office.
Very simply, it's done via SD-Mails. You designate who it is, within the office, that you want to have processing parts requests that the triage person has indicated are wanted. Triage information is conveyed to that person via SD-Mails that appropriately list each such part, along with any such added notes as may have been provided.
The new trick we've added is for the purpose of facilitating this office person's work.
Imagine he or she is looking at a SD-Mail that says so-and-so, as a triage person, has requested, say, these three parts should be ordered to go out with the tech on a particular appointment. Each part is shown as a line-item in the SD-Mail. You can imagine it's a bit of work if this office person must look within the SD-Mail, notice what is the JobRecord number involved, hit F7 to bring up the JobRecord form, hit "i" to begin an invoice number search, type in the number, then hit Enter to search -- then, once the correct JobRecord is shown, click on its "Order Parts" button. Of course, work is still not done because, absent automation otherwise, this operator still has to type appropriate information into the PartsRequest form.
What's the solution?
We've made it so this operator may simply double-click on a part-request line-item as present in one of these triage-request SD-Mails, and the system will instantly link to and open the JobRecord involved. It will likewise click on that JobRecord's "Order Parts" button and fully fill-in the PartsRequest form which then displays. Thus, a single double-click sets up the entire thing.
You may wonder why we have not made the system simply create the PartsProcess request directly, without an office person needing to be involved at all. It's possible we'll indeed do that in the future. However, for now our thinking is that you may want to keep an office person in the loop, thereby withholding from outside triage persons such absolute power as would be involved if their actions were permitted to directly create orders within your PartsProcess system.
Aside from this double-click to create internal part request in the triage situation hyperlink, we've created a couple of other hyperlink opportunities there. These can especially be useful if via ServiceDesk you've sent out an SMS text message and received back a reply. That reply will always indicate the smartphone number the reply came from. If applicable, it will also indicate the JobRecord number that the communication concerns.
As you look at your customer's reply, odds are high that you're going to want to locate any such JobRecord as is relevant. That's where this added hyperlinking ability comes into play.
Just double-click
on the indication of JobRecord number, if present, and ServiceDesk will
instantly display that JobRecord for you. If there is no such
indication, double-click instead on the indication of
smartphone number the reply was sent from. This will cause
ServiceDesk to open the JobRecords form and self-initiate a search on
the telephone number in question. Thus, via that means it will
instantly open the JobRecord of interest.
Improved Analytics for Insight Into Which Parts Are Sensible for Pre-Ordering in Triage, and Which Ones Are Not:
Tony Lott takes the credit for this one.
He called to describe the huge burden his operation endures in special-ordering parts for triage purposes, with a high percent ending up as having missed the mark, and then having to be returned to the vendor.
Tony wondered if there might be a way to identify parts that have a particularly high "miss" rate in triage. If so identified, there could be a warning -- when in triage a person is about to order such a part -- to say "Hey, maybe you shouldn't . . . this part has succeeded when ordered in triage only 5 percent of the time" (or something like that).
To fulfill this need, we've added two columns to the export that is available in conjunction with running a Usage Analysis report (shortcut sequence to get there is Ctrl-F8-->U, indicate your date range, let the report run and display to your screen, then click on the "Send this Report to Excel" button).
The two new columns are on the extreme right of the export. One indicates the quantity of each item that was ordered but not used. The other indicates the percent of items actually used, as compared to total quantity ordered overall.
The general thinking is that, when loaded into Excel, you sort on that last column. Thus, at the bottom of the sorted stack you'll see items that have scored very well, in terms of hitting the target of need. At the top of the sorted stack, you'll see those that have scored badly.
Given such visibility into items that have scored badly, you can use your judgment in deciding which items you want to add into your PartsHotList, and with appropriate notes accompanying.
If you are not familiar with use of the PartsHotList, it's simply a file you maintain with part numbers that, if someone is about to order such a part, they are alerted with whatever note it is that you want them to see. Facility for this was added 9/25/06 with release of Ver. 4.2.23 (search here on that "4.3.23" string and you'll instantly find the entry that announces the feature, and includes instructions on how to use it).
We hope, via use of this mechanism, you will
have enhanced visibility by which to intelligently curtail triage
pre-orders that are unlikely to succeed.
New Filter Option in JobsPerusal Interface:
There has long been an option in this interface (Shift/F7) to show only ShopJobs. Now there is an option to show only non-ShopJobs:
It's that simple.
Text Replies Now Go Where Text Replies Should Go:
It's been a couple of years since we first introduced SMS-based text-messaging as an alternate form of communication between you and your customers. Naturally, we keep expanding the options for its use and effectiveness. Regardless, there is one element of limitation that has until now persisted on the ServiceDesk side of SMS use. It is that, if your SMS recipient chooses to reply, we have had no mechanism by which to assure the reply goes specifically back to the office person who sent out the initiating text (instead, it's gone as an SD-Mail to the person that is designated within SD-CyberLink as general recipient for SD-Mails).
By way of comparison, this limitation has not existed in SD-Mobile. In particular, if the tech uses SMS as the method for a "call-ahead," and if the recipient replies, that reply has appropriately gone right back (as, obviously, it should) to the sending tech.
Now, the same "how-it-really-should-be" functionality works in ServiceDesk as well. It will be the actual sender who receives, as an SD-Mail, any text-reply from a SMS-text recipient. This should enable practices within ServiceDesk that are much closer to real-time, person-to-person texting (only with the office-side person working from within ServiceDesk, of course, as opposed to from a smartphone).
It's important to know, BTW, success in this
improvement depends on updating both ServiceDesk (to this version or
above) and SD-CyberLink (to Ver. 4.5.55 or above).
Improved Function and Definition for Initiating Auto-Dialing, SMS-Texting, Plain-Emails and/or User-Defined-Template-Based Emails and Texts:
While working on the above, we discovered that, as various features have over time been added in regard to what can be done via a telephone number and/or email address as present in a ServiceDesk Callsheet or JobRecord, we'd somewhat "mucked up" the set of keyboard and mouse actions that are available, and their results. In other words, there was not very good across-the-board consistency, agreement and uniformity. We decided a wholesale alignment of functionality was needed, and have now accomplished that.
In fact, we have created a new section in the Callsheet "Cheat-Sheet" to specifically describe each such potential action (in particular, as presently aligned for perfect and reliable consistency in every applicable context). If you do not recall what a Cheat-Sheet is, it's a listing of otherwise-hidden actions that you can do in a particular operating context. In each applicable context, you may display its Cheat-Sheet by doing a simple right-click on any point of the applicable form that is not otherwise functional.
Thus, if you right-click in any portion of a Callsheet that is not otherwise functional, you'll see the Cheat-Sheet that's applicable to Callsheets. In particular, you'll see it now includes a new section that looks like this:
Please note the second item among those above-highlighted -- in particular, the action to initiate a SMS text-message via a clicked-upon telephone number. Though that function is not new with this release, the present method is now different, as compared to what was prior specified. The reason is because, on doing this re-alignment, we discovered we'd inadvertently commandeered the same method (Ctrl/Rt-Click) -- as had formerly been specified for this action -- for the newer "Send template-based email or SMS" function (which you'll see as the item just below it, above). Obviously, you can't have the same method triggering different functions, so we had to move one of the functions to a new method. Thus, the "Send-SMS" function has been moved from Ctrl/Rt-Click to Shift/Rt-Click.
Please also note there is now clear differentiation between such action as is needed to initiate an email to each of multiple email addresses (as might be present in an email box), versus targeting a single email address. The general notion is you should be able to instantly and effortlessly (even intuitively, once you are in habit of using these methods) initiate any of these communicative methods via any particular telephone number or email address target, as already present in either a Callsheet or JobRecord.
Yes, the same actions will work precisely the
same from either a current or archived JobRecord. Regardless, the
above-shown Cheat-Sheet reminders are found exclusively in the Callsheet
Cheat-Sheet (in fact, the two JobRecord forms do not have their own
Cheat-Sheet).
Dedicated Handbook to Guide Customization of Automated and Semi-Automated Communication Scripts:
As
contrasted from the above methods (which involve initiating otherwise
non-automated communications), Rossware systems offer a great variety of
communications that are either fully or semi-automated. These may
be initiated by ServiceDesk itself, SD-CyberOffice or SD-Mobile, and may
proceed from either your office or, in the case of Tech "Call-Aheads,"
from technicians' mobile platforms. Likewise, they may (depending
on circumstances) be via email, RoboCall or text-messaging.
Fix for Old Telephone Numbers in Non-Standard Format:
As an otherwise un-announced improvement, we recently made it so that, post-editing, Callsheet and JobRecord telephone number boxes positively enforce standard telephone-number format (e.g., either XXX-XXXX or XXX-XXX-XXXX). Thus, if the text that you've placed into such a box was not in such standard format, but can be appropriately re-formatted, upon completion of any edit it will be. For some users, this has created an issue. It's because until now, they've been using a different-than-standard format (e.g., XXX.XXX.XXXX or XXX XXX XXXX). The reason it's an issue is because, with the system now enforcing the standard format, they end up with a portion of their data in standard and a portion not.
Another matter that sometimes arises is, back in the day, some service companies would not bother with inclusion of the area code where the applicable code was the same as their own. However, as telephone numbers have proliferated, it has become increasingly intolerable to assume any particular area code, so all-cases inclusion of the area code is now much more typically the practice. But, what do you do about all the older items in you data, in which the area code was omitted?
This new feature is designed to address both issues. The path to its access is deliberately obscure (it's not something you'll likely need to access more than once). Basically, from the archived JobRecord interface, press Shift/Ctrl/Alt/Right-Click. Then, just follow the dialog. It's self-explanatory from there.
BTW, the fact of having different formatting in telephone numbers now, as compared to older items in the data, is primarily cosmetic. A particular client thought it was much worse than that. In particular, they'd been using the dot-separator versus hyphen-separator format. So now they thought, with some telephone numbers in one format and some in the other, the only path by which to exhaustively do an as-you-type database search was to type once in the dot-separator format and again in the hyphen-separator format.
That is not actually true.
In fact, when typing in a telephone number in
any of the as-you-type database search contexts, it's best to type the
number with no separating characters at all. When you do this, the
system finds any and all telephone number matches, regardless of format
they are in.
Dramatically Enhanced Performance in Many Operations:
As databases grow larger, methods that once worked well sometimes no longer do. In particular regard to archived-PartsProcess records, some of our larger and very-long-term clients have accumulated hundreds of thousands of records. In a number of ServiceDesk functions, these very large files were resulting in unacceptable compromise. In particular, operations were either taking much too long or were searching less deeply into applicable history than would otherwise be optimum.
The problem is now solved.
To give you some idea of how bad was the issue and how effective is the solution, a particular client reported that one report was taking nine hours to complete!
Yes, that's very terrible.
With the new solution deployed, that same report now completes in seven minutes. (Yes, seven minutes is still a long time; however, it's an extraordinarily comprehensive report, and running it is not part of any ordinary daily operation.)
Even more happily, you'll find many ordinary and routine operations (indeed, the majority of any such operations that might have formerly consumed a second or two or three) are now dramatically faster. This is particularly and absolutely true for any operation that was slow because you have a large quantity of archived-PartsProcess records. All such operations will now search not only quickly, but also exhaustively (i.e., within the entire database).
SB-DispatchLink
Now Explicitly Accommodates Multiple Instances:
It's a funny industry. For some time, AIG and Assurant have both been sending dispatches via ServicePower. More recently, both began sending some of their dispatches via ServiceBench as well. It makes for a somewhat messy situation
Regardless, we have you covered.
As one needed element to address, there are now QET designations covering both of these entities in each brand of clothing (i.e., as connected to a ServicePower dispatch, and as connected to a ServiceBench dispatch).
As another complication, we needed to deal with the fact some servicers are now finding themselves in a situation where one or more third-party-administrator clients cannot be managed under a single ServiceBench account (thus, you end up needing to have more than one ServiceBench account). Since each instance of SB-DispatchLink has a single account designation, the only way to effectively accommodate this is by running a different instance for each such account. This could be troublesome if you wanted each such instance to run from the same desktop, because each would save (and read) its settings from the same location.
We've now solved this issue. Instruction on how to use the solution is provided here. (There is also a new button in the SB-DispatchLink utility itself, that will open the instruction for you. Plan to use it in the future, as a more convenient place to get the instruction, as compared to coming back to here.)
The same solution works, BTW, in the EmailedDispatchReciever utility (another place where we found users needing to run with multiple simultaneous instances).
Four Very Big
Items:
These items are being described in detail in an email blast that will go out shortly. For completeness here, we'll just briefly mention them.
We again have a super competent in-house iOS developer, so development of Apple-side products (in particular and especially the iPad version of SD-Mobile) will again be proceeding at a good pace.
New and awesome method to drive a large quantity of very positive online reviews (e.g., Yelp, Google Reviews, etc.) regarding your company (read beginning at Page 14 in the CyberOffice handbook for details).
Browser-based triaging center. It's done via a new website: triage.rossware.net. It should automatically work superbly for you, so long as you are using SD-Mobile.
This one is the biggest! You can now be a referrer via which your COD customers may potentially subscribe to Warrantech month-to-month service contracts. You get a portion of every month's payment premium, and many other benefits. Click here to learn more.
Miscellaneous
Fixes and Improvements:
At the NASC convention classes in Virginia, as always happens, we catalogued several requests for tweaks, additions and fixes (and thank you again Michael Basich for again keeping notes and compiling a list for me). Among other completions done from that list (several others are in SD-Mobile):
A fault in the new Inventory Deployments report is fixed.
Difficulty in deleting telephone numbers from the Rolodex is fixed.
System now informs of no match when linking to A/Rs from a JobRecord.
Improved tooltips in a number of places.
Made internal coding for G.E. claims (as made to ServicePower) automatically insert the needed Repair Code (i.e., as applicable whether it's a sealed-system versus normal repair).
Beyond this work, also responded to numerous email-forwarded error messages, to address any such weaknesses as allowed errors to arise. When working with one particular such item, discovered and fixed a systemic weakness in regard to how the system was managing multiple simultaneous instances of the F10 Inventory Control form.
New Instruction
Document on Setting Up for the Auto-Dialer:
Auto-dialing is a wonderful feature. Virtually any place that you see at telephone number in ServiceDesk, right-click or double-click and -- bada-bing, bada-boom -- ServiceDesk connects to your phone system and dials for you.
Most people are not using this wonderful feature. The main impediment has been in knowing how to set it up. So, we made an instruction document (click here).
As you'll by reading this short document, setup positively should be very simple. Check it out.
New Filtering Option in JobsPerusal Form:
ServiceDesk has a dandy built-in system to watch your back in regard to an expectation that a part may arrive on a date that's too late to be used on an appointment for which it is needed. In particular, as a parts-management person is indicating from within the PartsProcess form (F8) what is the ETA on an ordered part, the system automatically looks (behind the scenes) to see if there is a pending appointment. If so, it compares that appointment's date to the part's indicated ETA. If there is a conflict, the operator is alerted, and several options in solution are offered (including automated appointment cancellation and automated emailed notice to the customer, with option for them to online re-schedule on a date that is conducive to the part's ETA).
That's all cool, but Krystle McConnell at Lake Appliance Repair wished for another option. In particular, she did not want her parts management person to be involved in accepting such automated cancellations as are above described, and instead wanted a different person (perhaps one that better specializes in human interactions) to have ability to regularly review each/any job on which this kind of conflict exists, and to thus call the customer, explain and discuss, re-schedule, etc.).
So, we made the ability.
In particular, the JobsPerusal form (Shift-F7) now sports a new sub-option when you select the main filter category of "Scheduled, Awaiting Dispatch." It's shown circled here:
We believe usage is obvious.
New "Inventory Deployments" Report:
When you are appropriately using ServiceDesk's Inventory Control system, you will periodically be conducting physical inventories -- to see how actual presence of stock at each location compares to ServiceDesk-indicated stock, and to then adjust quantities as reckoned by ServiceDesk to fit what is physically found.
All but inevitably, there will be at least a few discrepancies, and often they are for near innocent reasons. Maybe once in a great while, for example, an otherwise excellent tech forgets to list a minor part that he used (if he doesn't indicate it's use, obviously, the system cannot know it should decrement the reckoned quantity). Potentially, the opposite might occur. Less excellent techs might make such mistakes more often, and more grossly (i.e., forget to indicate use of major and expensive parts, and with significant frequency).
Of course, not all cases are innocent at all. Some may be nefarious indeed, as where a tech is doing his own work independently, and is using your parts on his jobs! (Most service company owners who have employed a significant number of techs over a significant period have seen this happen.)
Besides doing periodic physical inventories, another process that facilitates registering discrepancies is when a tech indicates he used a part from stock which the system did not reckon he had, or when he tells you he has no stock on an item the system reckons he should have. In either case, the system accommodates ad hoc adjustment to reckoned inventory, so as to make it equal what is the evident physical reality.
Regardless of the process for making adjustments, there is always an entry recorded to reflect the fact it was required (it's made to the "Journal of Inventory Movements"). One of our notions in such connection has been, if you suspect a tech of potentially having been overly careless (or perhaps even nefarious) in regard to such inventory items as are entrusted to him, you may review such adjustments as have been required. On that basis, you can make a judgment as to what is probable in such regard.
The problem is, it's a bit painstaking to review these journal entries for the purpose of forming a coherent picture. It's more painstaking, still, if you want compare between and among your techs. So, we made a new report that places perfect information right in front of you (try to ignore the date range and actual numbers as shown; such wierdness is in consequence of the fact I am still using old data, from my former service company, for development and testing):
In the above you can see both the nature of such data as this new report provides, and the path (from within the F11 Reports form) that is needed to produce the report.
Option to Make the "Merchandise" Category of Sale Non-Taxable:
In general, ServiceDesk contemplates that for any sale situation there will be a tax rate that's applicable to materials and one that's applicable to labor. In any SalesJournal entry, there are two columns that are considered to be subject to the materials rate (Merchandise and Parts) and two columns that are considered to be subject to the labor rate (S.Call and Labor).
With the above as backdrop, some folks have elected to use the Merchandise column for things such as mileage, handling charges, etc. Likewise, for some such folks, these are categories that in their jurisdictions are not taxable. So, it was requested that we add an option to make the Merchandise category non-taxable. That option now exists.
To select the option, simply go to your Settings form (Ctrl-F11), and activate the new checkbox option as shown here:
Finished-Form Emailed Tickets Now in .PDF Format:
For a number of reason that we find compelling, e-tickets as sent by SD-Mobile (and/or as sent by SD-MobileLink) are sent in .PNG format. It's a strategy we presently intend to maintain.
When you're working directly in ServiceDesk, by contrast, and it's your intent to email an invoice from within the FinishedForms context, we believe the dynamic is different. In particular, we believe for this context dynamics may weigh in favor of using .PDF.
Thus, we have modified the system so that, in this particular context, the system now sends a .PDF attachment rather than a .PNG attachment.
Expected Core-Returns Now Included in PartsPick Form:
We thank Jeff Miceli from Appliance Tec for pointing out a very major faux pas.
We built the PartsPick form (Shift/Ctrl-F8) to provide a super-efficient venue in which to see (and check-off appropriate movement) of each item that needs to be provided to a tech for his day's roster of jobs, and each item that needs to be retrieved back, because previously provided and not used (whether it was a special-order or spec-tagged item).
It's really a super system. However, there is something it was not doing that positively it should have been doing.
Besides showing items needing retrieval that are in the special-order or spec-tagged category, this venue obviously should have also been showing expected core-return items. Honestly, until Jeff pointed it out, we did not realize we'd omitted such an obvious element of functionality.
However, it's there now.
So long as, on any special-order item, you have appropriately created the expected core-return daughter band (which positively should be created when you know the primary item has a core-return fee), when the tech has indicated use of the primary item, the PartsPick form will list an expectation for return of the core. As with other expected return items, you should only check-off the item when and if you get that core back.
(As a side note, the next item on our agenda in regard to core management will be to extend it to inventory items; presently, express core-return management applies only to special-order parts.)
Enhanced Export to QuickBooks:
We've had an Export-to-QuickBooks feature for many years. In nutshell, you run a SalesSummary report from the Reports form in ServiceDesk (F11), then click on a button to initiate the export. The sequence creates a .iif format file (stands for Inuit Interchange Format), which, when you then import into QuickBooks, creates a series of journal entries, in QuickBooks, that summarize such accounting processes as ServiceDesk took responsibility for.
One aspect of this has been slightly less than favorable. It is that the particular accounting entries -- that you are about to import into QuickBooks -- are something of a black box, until after you do the import and see what resulted, by looking within QuickBooks itself. Technically, you could look in the .iff file to see, but the formatting of data within that file does not lend itself to easy decipherment.
So, the system now simultaneously (while creating the .iif file) also creates a .csv file. When opened in Excel, this .csv file makes it very easy to see what are the particular entries (as debits and credits) that will result in QuickBooks when the corresponding .iif file is imported:
If you are at all familiar with accounting, you know the first numeric column shows debits and the second shows credits (you also know the expressions do not simply mean money-in or money-out, as they do in your checking account ledger).
In addition to this improvement, we also added a system to alert you if the numbers as tallied indicate a reason to suspect a problem with such data as was entered to the system.
Option to Indicate Specific-Purchase-Invoice-Number as Inventory Parts are Used:
The need for this feature arose in conjunction with a client who does much work for Samsung. Turns out Samsung requires this client to claim, on each part used, via the same invoice number on the actual replacement part was purchased. Samsung enforces this requirement by demanding that the old part be returned in the same bag or box that contained the replacement part. That bag or box has a label on it (placed there when Samsung shipped the part) that indicates the invoice on which it was purchased. If the claimed-upon purchase invoice number does not match the number on the bag or box in which the old part comes back, there is a rejection of the claim.
Given this, we had to make a system whereby, as a tech uses each/any part from inventory, he can look at the purchase invoice number that's on its label, and tell the system that's the one he is using (this way, the system can then assure that's the one that's pulled from inventory, and that the same invoice number that automatically goes into the claim).
If you have need for this same alteration in functionality, you can toggle to make this the mode by bringing up the contextual "Cheat-Sheet" from within ServiceDesk's Inventory Control form (F10 is the shortcut for the form, obtain the Cheat-Sheet by right-clicking on any otherwise non-functional space within the form). You'll see the following (circled item), as a new Cheat-Sheet option:
By clicking on it, you may toggle between having this new option turned off (the default) or turned on. If turned on, of course, the strategy will override the default strategy, which is to pull the cheapest instance of an item if it was used on a COD job, or the most expensive if it was used on a warranty job.
If the feature is in fact turned on, your technicians in SD-Mobile will see a dialog something like this, when they are submitting any PVR on which they have indicated use of parts from inventory:
Thus, for each item used, they'll simply indicate (from the provided list) which of the applicable purchase invoice numbers (from within your stock overall) was the one involved as based on the label they see on its bag or box.
BTW, for operability this feature also requires an update to SD-MobileLink Ver. 2.0.93 or above, and to SD-MobileLink Ver. 2.0.68 or above.
Also (this is very important), please note the functionality that uses this has not yet been added into the iPad version of SD-Mobile (aka SDM-i). Please do not at this time turn on the feature if you have techs using that platform. Those techs will have no provision to indicate the invoice number on which each item they used was purchased, and, in that absence, your option to turn on the feature will really throw a wrench into workings of the system.
Default-Restored to Continuously Chime when Indicating Un-Read SD-Mails, But with New Option to Single-Chime:
Two updates back we were pleased to announce that we'd removed the super-annoying constant chiming that occurs when the system is urging you to view an un-read SD-Mail item. We changed it so that instead the system gives you a single chime.
Wouldn't you know it. We received calls from a number of users who want the constant chiming back.
So, it's back.
However, there is also an option (if such is your preference) to go to the single-chime method instead. It's in the green section of the settings form (hence, it's a setting that's particular to each user) as shown here:
Thus, each user may select per preference.
Mouse-Click Initiate-Communication-With-Tech Options:
We have "jillions" of features to facilitate automated and semi-automated communication, whether it's between you and your customers or between and among staff persons within your business. In particular (for communication between staff persons) we have both SD-Mobile (which automatically communicates standard job info outward to the techs and standard performance/completion info back to the office) and the SD-Mail system (among other tools).
Regardless, even if wanting to send a particular tech an SD-Mail, more than a single click (or keyboard stroke) is required. First, you're going to find the SD-Mail function in the general menu (via multiple mouse clicks) or use the keyboard shortcut (Ctrl-F12). Then, you'll either pick the tech of interest (via another mouse click) or you'll type-in his two-character abbreviation.
Suppose you're already looking at the tech's listing (i.e., the one you want to contact) within the DispatchMap, in the Settings form, or in the Create-Job/Sale form. And/or suppose that, instead of sending him an SD-Mail, you want to call him, send him a text-message or, perhaps, a standard, internet-based email.
It's for these kinds of interests that our new feature (suggested by Michael Basich, of Michaelson's Appliance in Tampa, FL) was created.
From any of the above-identified contexts, you may now do Shift/Click on a tech's name, and you'll see something like this:
Just pick the option that interests you, and, instantly, you'll find yourself in a mode to proceed straightforwardly in the indicated task (if picking the "Telephone call" option, the system auto-dials the tech's number for you).
In regard to the telephone number that's used for auto-dialing (or text-messaging), there is a corresponding little change we've made that here bears description.
Prior to now, if you click on a tech's name in your listing of technicians in the Settings form (Ctrl-F1 is the shortcut), and then see the Technician Properties window as applicable to that tech, you would fail to find any box as provided for you to indicate the tech's telephone number.
You would, however, see a box provided for you to indicate the tech's Pager Number.
Yes, that's right: his "Pager Number!"
That is, perhaps, an indication of how far back Rossware systems were providing automation.
But of course today there is virtually no one that is still using pagers. In particular, we don't believe a single Rossware client is now using them as a means to contact their technicians.
Hence, we have changed the box that formerly was indicated for provision of a tech's Pager Number. It's now intended for use of indicating his Telephone Number (probably his cell number).
It is this number that will be used by the
system, if you pick the option (as above described) to initiate a
telephone call to an applicable tech, or to text-messsage (this
particular change, BTW, was suggested by JD at Guinco in Fort Worth,
TX).
Default Own-Company Selection in Rolodex:
Do you use SD's Rolodex (keyboard shortcut if F4) as the place to keep track of contact info (telephone numbers, email addresses, etc.) for your own personnel.
That's precisely what we do here at Rossware. Even though we are not a service-call performing company (obviously), we nevertheless use a couple of elements within ServiceDesk for our own operation. We use the Callsheets, for example. And we use the Rolodex.
In fact, though we have many companies and persons listed in our Rolodex, I noticed that most of the times when I go there looking for a listing it's for a person in my own operation. It thus was beginning to seem a little annoying when I must scroll to find the company listing of Rossware Computing, Inc., and then find the person of interest as a sub-category. Hence, the new feature.
If a company listing in the Rolodex is structured with the company name as a precise match for what you see (as your company name) in the ServiceDesk About form (keyboard shortcut is Shift-Ctrl/A), ServiceDesk will now default-select that company when the Rolodex first displays.
User-Created and User-Based-Subject-Matter Email and SMS Template Usage:
We credit Tony Lott, of Appliance Express in Texas, for this one.
He emailed me, expressing how much today's consumers are learning to prefer electronic communication over phone calls. Of course, his office does too, because emails and text messages are much more efficient and less taxing of limited personnel resources.
Rossware systems already offer, of course, a large number of mechanisms that are designed to accomplish defined kinds of communication electronically (e.g., initial requests to schedule, requests to re-schedule after parts arrive, confirming appointments, etc.). However, there will always be a limit in the variety of defined communication types that we can reasonably design for. Tony's office found itself in a situation where they wanted to define a number of their own communication context types, so they created (and have been using) "templates" for those.
Tony's suggestion was simple. Why not create a provision in ServiceDesk where it can "call out" to such templates, fill in the spaces appropriately, and directly send a perfect email or text-message, as user-selected for the context.
So, that's what we now offer.
Full instructions are in this document.
A Clarification Regarding Fees:
Tony made the kind suggestion that building this feature might be a revenue enhancement for Rossware, via added email and SMS charges. It raises a matter I wish to clarify:
There is no fee from Rossware -- whatsoever -- as connected with sending emails. There is a fee for RoboCalls and there is a fee for SMS messages. I would like to assure everyone understands the difference.
In regard to any of these methods, ServiceDesk may be thought of as the physical telephone in the old-fashioned AT&T voice-communication network. Since you purchased ServiceDesk and via support pay for its updates, your "telephone handset" is covered by that, and there cannot properly be any separate and/or additional charge in its connection.
Thus, when you send an email (and even when you use ServiceDesk to do it), Rossware is not equivalent to the old AT&T. We are not the "carrier" that transmits your email to its recipient. We only provided the telephone handset (which you've already otherwise paid for), and nothing more.
When you use ServiceDesk to request a RoboCall or SMS message, by contrast, Rossware is in that context equivalent to the old AT&T -- in that we provide, in addition to the telephone handset itself, actual means of communication. It's added mechanisms we provide, in other words, that are the "carrier" in this context. We actually buy these mechanisms at wholesale and resell to you at retail. That's why there is a fee, and it's why it makes sense for us to charge separately in this context, but positively would be wrong and unfair for us to charge for sending emails. Again, you already bought the handset, and it is not Rossware-provided instrumentalities that transmit your emails across the internet.
Drag-and-Drop Additions to QuickPics from Within SD:
QuickPics are great. Techs snap pictures with their smartphones; resulting images are automatically attached to each applicable job and machine -- and forever thereafter are immediately available with a simple contextual click. You may even include descriptive captions. Meanwhile, you bear no burden of storage and/or organization. It's all done for you.
But what about when you have a picture file already in your office (i.e., it's a JPEG file in your computer), and you want to put this into that magical QuickPics store?
Until now, there's been only one vector of insertion, and that's by snapping pictures via the provided smartphone apps.
Now there is another vector.
From within Windows, simply drag-and-drop any JPEG file onto the camera icon of a ServiceDesk JobRecord (Current or Archived; it does not matter):
You'll see a little dialog box like this:
Simply provide some descriptive text, then hit Enter. If there are one or more UISs connected to the Job, you'll also be asked in regard to potential attachment to them. Simply proceed with the dialog. With such simple action and scarcely more than seconds, you'll have the desired pic forever attached, as wanted.
BTW, the system is just as flexible as is Windows in
regard to where you can drag-and-drop from. Directly from your
desktop is perfectly fine, for example. Or, suppose there are one
or more pics that are attachments in an email. At least assuming
that you are using Outlook or similar, you can drag-and-drop directly
from those, as well.
Peace and Quiet in the SD-Mail System:
We thank Michael Basich at Michaelson's Appliance for this one. He told me his office is not using the SD-Mail system, because they cannot tolerate the chiming that occurs to alert of unread mail items.
One solution, of course, is to look at unread mail items. Once you look, they are "checked-off" as read, and the chiming ceases (well, until the next new SD-Mail arrives).
Regardless, it is not always practical to immediately look, and in the meantime that constant chiming can be annoying. (I hear you, Mike, in regard to you hearing this chiming annoyance.)
So, now it is changed. Now, in any given ServiceDesk session, there will be only a single chiming sound as any new SD-Mail arrives. When you newly start a ServiceDesk session, there will likewise be a single chiming sound (within about 20 seconds of starting) if your SD-Mail InBox contains one of more unread items.
That's it. That should be all the SD-Mail chiming annoyance going forward.
On the other hand, so long as you have unread SD-Mail items, flashing at top of the screen (so as to keep you visually alerted of items) will continue and persist (i.e., just as the sounds also used to persist).
Vastly-Expanded Options for SMS-Text-Messaging and RoboCalling:
For the longest time, ServiceDesk has offered a plethora of automated and semi-automated email-based methods by which to accomplish needed communications with your customers. A few years back, we added RoboCalling as an optional method for the appointment-reminder/confirmation-request context. About sixteen months ago, we added SMS text-messaging as a third option for that context.
All the above was good, but, in the interim, we've received many requests to have RoboCalling and/or text-messaging added as options in other contexts. That's what we introduce now.
Text-messaging Replies.
If you've been using text-messaging in the
appointment-reminder/confirmation-request context, you know that
occasionally (even though the text in itself asks your
SMS-correspondent to click on a link so as to confirm the
appointment) the recipient texts back with a verbal confirmation or
other message. You further know we've configured for this
text-reply to be handled via creation of a SD-Mail, which shows you
the text from the customer's reply:
The problem is, there has been no convenient way for you to respond
back via text. Now there is. Specifically, if you are
looking at one of these SD-Mails, just click to Reply.
Automatically, the system will recognize the context, and configure
to send your reply back as a text:
On-Demand,
Self-Initiated, Direct Texting. So, you simply want to
initiate a text to a customer (or perhaps to an employee or other
associate), and you want to do it from your desktop rather than from
your smartphone. You have a telephone number that you know
belongs to the intended recipient's smartphone. For this
situation, simply use a new variation we have added to auto-dialing.
The general command to auto-dial (from almost any context where a
telephone number is listed) is to right-click on the number.
If you wish to text instead, simply make it a Shift/Right-click.
This will open the SD-Mail compose window, pre-configured in mode to
text to the number you initiated from:
|
|
Request to Schedule
After Parts Arrive. Whenever you check-in a
special-order part, the system automatically checks to see if more
parts are still on order for the underlying job. If not, it
invokes a dialog. In particular, if it finds that you have an
email address for the customer, it offers to send the customer an
email, informing you have the needed parts in, and requesting that
the customer schedule their completion visit. Now the dialog
offers a more expansive set of options:
Old Dialog: | New Dialog: |
|
|
POS-Context, Request to
P/U After Parts Arrive. This is a close parallel to the
above, except the involved communications are asking the customer
simply to pickup their parts, as opposed to asking them to schedule.
The dialog looks like this:
Old Dialog: | New Dialog: |
|
|
Other Requests to
Schedule. You get a request from a
home-warranty-company client to contact a consumer to schedule your
visit and perform a repair. Or, you get a request from a
landlord to do similarly in regard to a tenant's location. Or,
you are seeking to try again with a customer that's not responded,
asking again for them to schedule for completion after parts have
arrived. In any such case, it's long been true that you could
right-click on JobRecord's "Scheduling" button to receive
some emailing options in this regard. Now the resulting dialog
is more expansive.
Old Dialog: | New Dialog: |
|
|
Please bear in mind both RoboCalls and SMSs carry a small fee (going forward it will be nine cents and three cents each, respectively . . . reduced from the former price of a dime and nickel a piece; we thought it best to avoid any claim about "nickel and diming" our clients).
Integrated 2nd-Man-Required Functionality:
Earlier this month we added a function in SD-Mobile whereby a tech can directly indicate that a second-man/helper is needed on his return visit (he simply checks a box to so indicate). When he has so checked, the system will create an informing AttentionNote in the JobRecord (this is in parallel to what it does when the tech indicates that his return appointment should involve any JobCount value above the default of 1).
While an AttentionNote is nice if look at it, there is (of course) always the chance it will not be noticed. Thus, as another parallel to how above-1 JobCount requests are handled, ServiceDesk will now look, when you are scheduling from a JobRecord, to see if there is a second-man-required AttentionNote. If so, it will remind you of the circumstance, and even offer to prep entry of the second appointment for you. Likewise, once you have created the second-man "Hlpng . . ." appointment, it will delete the AttentionNote.
On-its-Face Indication from JobRecord of S/O Parts Involvement:
If you want to know at-a-glance if a JobRecord has special-order parts involved, there is now on-its-face, visual indication:
The trick (as illustrated above) is any job that has s/o parts involved will have its "Order Parts" button rendered in green.
FundsJournal Entries Now Fully Editable:
Until now, if you wanted to edit a FundsJournal entry in any display mode aside from viewing current entries and in a non-search context, the system would not permit you to do so. Now you are permitted to edit from any display context, including past entries and search contexts. If editing past entries, an extra layer of password protection is invoked.
Instant Link to SalesJournal and A/R Searches:
Imagine yourself in a JobRecord when, for whatever reason, you wish to know what SalesJournal entries have been made in its connection. Or, you wish to know what A/Rs (if any) are pending. Certainly, it's easy to go to the SalesRead form (Shift-F3) to conduct a search, or go to the A/R form (F3) to conduct search.
However, it's not easy enough.
We already had, within the two JobRecord forms (Current and Archived), a hotlink to the FundsJournal form (Ctrl-F9), used so as to instantly see what funds have been collected in connection with a job. It's accessed by right-clicking on a JobRecord form's "enter Funds received" button. Now the ToolTip for that button (obtained by floating your mousepointer over it) indicates further functionality:
And now, when you indeed right-click on the button, you get a set of options as follows:
Pick the option desired, and you'll get instant information accordingly.
Built-in Summary-of-Nets in SalesJournal Search:
When you search in the SalesJournal for entries connected to a Job, whether your search is initiated directly from within the SalesRead form (old-fashioned way) or via the new HotLink (described above), there is a new connected feature. Specifically, the system will provide you with a net summary of values involved:
You don't need to do anything special to make this summary appear. It should just happen, on its own.
Automated Cancelation of Whirlpool OOW Jobs:
We'd thought this had been taken care of ever since 2010. Turns out our belief was mistaken. The SB-DispatchLink functionality that was designed to automatically cancel zero-sale referred dispatches (so you don't have to pay a referral fee) was indeed doing what we'd been told needed to be done for the purpose. It turns out, however, that what we'd been told needed to be done was not actually sufficient. Upon so learning, we determined what would be sufficient, and released a new copy of the SB-DispatchLink utility (Ver. 4.8.7) that now succeeds in this important purpose. If you've formerly been doing these cancellations manually, you should find that, going forward (so long you update to the above-indicated version or later), there is no longer a need.
Two-click Closing of Job as Zero-Sale:
Some people don't realize this, but it's best for every JobRecord to be closed via an appropriate entry to the SalesJournal. In other words, even if there was no charge (e.g., the customer canceled before your technician got there; it was a recall, etc.), it's best for a real SalesJournal entry to be made, even if in zero amount.
One reason this is best is because it officially documents what happened to the job, in terms of its resulting sale amount. Another reason is because, when eventually you are audited by the IRS, that nice man or woman is going to be looking for invoice-number gaps in your SalesJournal (suspecting maybe any such gaps are cash sales that you kept off-the-books). If you have no such gaps, you're going to be in much better shape than otherwise.
Still another reason it's best is because, if you participate in Whirlpool's OOW-referral program, that zero-amount SalesJournal entry serves as the basis by which the SB-DispatchLink utility knows to automatically inform ServiceBench that the referred job was canceled, and to thereby remove it from the list of items on which you'd otherwise be charged a referral fee.
Prior to now, ServiceDesk has had a means to automatically make a zero-amount SalesJournal entry for you, in conjunction with canceling an appointment. Basically, a dialog asks if just the appointment is being canceled, or if the job is as well. If you answer the latter, the systems offer to auto-enter a zero-amount SalesJournal entry for you.
But that circumstances does not always fit, and where it has not the remaining option has been to make a zero-amount SalesJournal entry manually.
Now we've made a direct-purpose shortcut. From any JobRecord that you want to close-out with a zero-sale (and assuming it does not have an appointment to cancel as a means by which to accomplish this), just click on its "Recorded to SlsJrnl" status button. The dialog that's comes up now looks like this:
When you pick that option, it opens the SalesEnter form with the entry line already filled-in for you. You just hit Enter, and the task is done.
QET Export:
Not sure why, but some people wanted to export data as applicable to their QuickEntryTemplates. So, there is now a button for the purpose:
Just click, and follow the prompts.
Overhaul of EDA Mechanisms:
(1) EDA files are now moved from NetData to a dedicated folder called EdaFiles. (2) User will now be offered a default filename that is sensible for the circumstance (e.g., AHS.4P4.EDA where AHS is the specified payer and AHS is setup as a HVC), or MiscellaneousCustomer.4P4.EDA where it’s a non-HVC payer). (3) User will be warned (and guided toward better understanding and action) if using a new filename that reflects solely the date, credit memo number, or similar. (4) User will similarly be warned/guided if using a new filename where one or more files already exist containing the same alpha string (i.e., if I am making AHS456 and AHS123 already exists, I’ll warned)
Improvement in Connect for Assistance:
Altered interface so it makes it much more likely user will make correct choice.
4.8.22 (3/24/17):
Twice as Many Processors to Pick from when Using Virtual Terminal:
Since we introduced integrated credit-card processing several years back, our Virtual Terminal has worked with just one merchant processing company: Cayan (formerly Merchant Warehouse). Sometimes people wanted a choice. Now you have one.
We are pleased to announce Rossware's association with a second merchant processing company: Altiras. We made the very large investment, as needed to make the Virtual Terminal work with this new company, because we believe they are outstanding.
If you are not presently using Rossware's Virtual Terminal, you should be. You'll reduce the time and effort that's involved in running transactions. You'll enhance accuracy and save money. Better yet, Altiras has setup a website and dedicated two human representatives to specially serve the needs of Rossware clients. If you're not already with Cayan and happy with them, we highly recommend that you contact Altiras immediately.
You will, BTW, notice a new control within the Virtual Terminal interface:
As you can see, its simple purpose is to let you indicate which of the alternate processors you are using. If you are presently setup with Cayan, don't worry. Presence of the new option should not affect your operation at all.
Will Soon be Available for Canadians Too:
That's another major reason we made the investment to work with this new processor: unlike Cayan, they can do processing for our beloved Canadian compadres.
That's right. Until now Canadian users of ServiceDesk could not use our terrific Virtual Terminal. With Altiras, they will be able to. The one catch is that coding details as needed for Canadian transactions are a little different, and we have not yet done that added coding. We expect to have it done soon.
Enhanced Comprehensive Searches:
In the last release we announced addition of a new "comprehensive" search option in the current- and archived-JobRecords. What we mean by "comprehensive" is the system will search for all text everywhere, within each JobRecord, for a match to whatever is your search target. In other words, it will simultaneously look in the name fields, address fields, telephone number fields, description of symptoms, narrative histories, ExtraNotes and MoreInfo, etc.
For reminder, this comprehensive search is invoked by use of the Windows-universal search command: Ctrl-F ("F" is for "Find"). If you do this from within an archived-JobRecord, the system assumes it's within archived JobRecords that you wish to search. If you do it from within a current-JobRecord, the system assumes in a parallel manner, but, absent finding any match, offers to automatically extend your search into the archive.
As great as was this addition in its own right, it lacked something. That something was already present in the similar comprehensive search that exists in current-Callsheets (invoked via the same Windows-universal Ctrl-F when in a current Callsheet). It is simply this:
When ServiceDesk finds an item that includes a match to your target, it does more than simply display that particular item (Callsheet or JobRecord). It likewise highlights within that object the particular text that's the match to your target. That way your eye can readily see it.
It's much better this way. Try it; you'll see.
BTW, this improvement was also applied in archived-Callsheets (formerly, it was only current-Callsheets that had the feature), so it now applies in all comprehensive-search contexts.
Print for "All-Techs" New Option in PartsPick Form:
The PartsPick form (Shift/Crtl-F8) was designed with intent that the person in your office who's responsible for moving parts to and from the techs can use the interface live, likely via a tablet, as he she pulls parts from the shelves for each tech, retrieves items back from the tech's return basket, etc. Regardless, because a number of people still like paper, there's long been an option to print for each tech the list of items that should be moved to and fro. But this printing was done individually for each. In other words, you select the tech then pick to print. If you have a lot of techs and want a printout for each, the process could be tedious.
Now the same button that's been used to print for each tech (in the bottom-right corner of the form) behaves a little differently. If you have no tech selected and click on the button, it will assume you want to print for all techs, and act accordingly. If you have a particular tech selected, it will present this dialog:
So, it's pretty simple to get whichever result you want.
Items Anticipated for Future-Scheduled-Use Now Show for Retrieval in PartsPick Form:
Your tech was out on a job with one or more special-ordered (or spec-tagged) parts. For whatever reason, he did not use one or more such parts. However, the job is not done; he is scheduled to go back on another visit, and he still anticipates using such parts on his next visit. Should the system prompt for you to retrieve such particular parts back from him?
Until now, the system did not so prompt.
Now it does. It however prompts in a special color for the
circumstance (grey) to bring notice to the fact that, depending on your
preference, you may or may not want to insist on getting such parts back
at such time.
Direct Emailing of QuickPics Now Available:
Since we introduced the SD-QuickPics feature a few years back, we have often been asked how to include these pics in emails. The answer: it's easy. So long as you have your Windows configuration setup to open the file type (.jpg) in a competent viewer (Windows Photo and File Viewer is typical), you can use mechanisms right within that viewer to email the pic. Honestly, we did not feel enthused to build internal-to-ServiceDesk mechanisms when it's so easy to do it otherwise.
However, in our class at ASTI last month, some attendees pointed out this emailing context does not auto-fill email addresses. Nor does it provide an implicit method by which to include multiple pics within a single email.
Okay, we were persuaded.
Previously, the listing of pics as attached to a Job (or UIS or Visit) would look something like this:
Now it looks instead like this:
As you can see, it's different, and along the bottom contains specific instructions on how to select either a single or multiple items to direct-send via email.
SalesJournal Lock-Against-Edits Partition, New Options for Automation:
Your ServiceDesk SalesJournal is the official accounting record of your sales. If entries have been entered wrongly there, it's fine to edit to correct them, so long as such entries have not yet been directly relied upon for external purposes (i.e., in compiling income statements, tax liability reports, etc.). Once there has been such external reliance, it's important to leave such entries alone. Instead of editing such an entry if it was in error, a new entry should instead be made that adjusts for whatever was wrong in the prior one.
Last year (with release of Ver. 4.7.134) we added a feature to help you police yourself in such regard. Basically, you can tell ServiceDesk to lock-against-editing all SalesJournal entries that precede a particular date (call it a "date-lock partition"). That new feature is accessed through this button in the SalesJournal-Read form (Shift-F3):
We did not it leave solely up to you to think to periodically update the location of that partition. In particular, we simultaneously included programming to make it so, when you complete an export to QuickBooks, the system auto-prompts with a query asking if you'd like the date-lock partition to be moved, for you, to the ending-date of the period you just exported to QuickBooks.
In our class at ASTI, folks requested more options for automation than this. So, now there are several. In particular, if now you click on the button as shown in the illustration above, you'll see this (with new option highlighted in yellow):
If you select that new option, you'll see this:
As you can see, there are many options you can pick from. Pick the one you want, and ServiceDesk will behave accordingly.
Comprehensive Search in JobRecords:
We've always had superb searching options, especially in regard to JobRecords (both current and archived). We have index-based searching that is instantaneous as you type (in regard to customer names, addresses, telephone numbers and emails). We likewise have search bases where the system looks directly within the JobRecords, looking for target matches on any of the above, plus things such as P.O. Numbers. The archived-JobRecord context (Ctrl-F7) has additionally featured searches on street names and any targeted word or phrase within narrative histories.
Okay, good foundation . . . what do we have now?
A few years back we added a comprehensive search into current-Callsheets (one had existed in archived-Callsheets long before that). With your Windows focus in a Callsheet, just hit Ctrl-F (it's the universal in-Windows command to invoke a search; the "F" is for "Find"). Type a textual-search target and hit Enter. The system will immediately search through all current Callsheets looking within all text of each (including Extra- and MoreInfo-Notes) for any instance of text that matches your target. Upon finding any match, it will show it to you.
One day we realized we really should have the same kind of ability in JobRecords. So, now it is there.
From within either a current or archived JobRecord, hit Ctrl-F on your keyboard. Type in whatever text target you are interested in seeking (yes, universals are permitted; just look at the prompt), then hit Enter. If the first shown match is not the one you are seeking, you will see via the prompt you may renew by looking for the next match, etc.
BTW, a big element of new accessibility via this search is narrative Job-Histories in current JobRecords. Until now, there was no search provided for text in that specific context.
As a slight aside, if you have your Windows focus in a narrative JobHistory and wish to select the entirety of the text (maybe to copy to your Clipboard for insertion elsewhere), another tiny addition is you can now do that using the standard Windows command for "Select-All." The command is Ctrl-A.
Enhanced Auto-TimeFrame-Estimator:
The DispatchMap has long had a feature that will insert timeframes for you into a technician's series of appointments, based on parameters you specify (e.g., length of timeframe, average time from one stop to the next, etc.). Since it's much easier to reliably predict when the tech will arrive at his first stop, some companies like to give each first-stop customer the courtesy of a smaller timeframe (maybe just an hour or even 30 minutes). The dialog that's involved in the Auto-TimeFrame-Estimator now has provision to accommodate this.
Option to Disguise Retail Pricing on Parts Labels:
We're kind of surprised this one did not come up sooner.
If you have variable pricing on your parts depending on circumstances, it may be awkward if you have a label on each part that clearly shows some price other than what you actually charged the customer. Hence, you may want to disguise the price, much in the manner that cost has long been an included element on these labels, though it's disguised in a manner (hidden among other characters) that makes its value unobvious, unless you are acquainted with the format of disguise. Anyhow, we now offer the same option in regard to retail price.
To invoke the option, go to the PartsProcess form's (F8) Cheat-Sheet (just right click anywhere in the form that is not an otherwise operational place).
Select the option that's indicated above, and you'll then see a dialog where you can turn "Disguise Retail Price" on or off.
Global Search Characters Now Functional in Archived-JobRecords P.O. # Search:
This option was long available in the Current-JobRecords form, but (for whatever reason) we discovered it was not available in the Archived-JobRecords form. There are various global-search-character schemes (the general idea is you can put a fake character in your search target, and a potential match can have anything at all in that position). Our scheme is simple. Just use can use an asterisk as a global:
As you can see, the prompt has instructions on this, in case you forget.
Multi-Select (and Multi-Job Summaries) Now Available via F12 Search:
Most new features are based on user suggestions (which are sometimes close to being more like requests, or even demands). Occasionally, an idea pops into my head independently. Often it's the kind of thing where, as I am working in an interface (helping a client or testing functionalities I've just tweaked), it occurs to me that it "feels" like I should be able to do a particular thing . . . and, damn it, if your senses tell you that it would be an intuitive thing to do, really, the interface ought to allow you to do it.
This was one of those instances.
I found myself looking at the results list (references to jobs) in the F12 form. It occured to me I might want to print (or email) a summary regarding a particular selection of jobs from that list. How obviously logical it would be if I could multi-select the particular references whose job summaries I wanted to include, and then print or email accordingly?
So, that's what this new feature is. Go to your F12 CstmrDbase-Search form. Type in any text target. From among the listings that result, use standard Windows multi-select to pick the items whose job-summaries you wish to have detailed in an overall summary, then click on the button to proceed:
The dialog that follows is where you'll pick to print or email.
Miscellaneous:
Date-picker calendars have been added to the onscreen NARDA's date boxes (it means, if the date is not already auto-filled, you may select as wanted from a calendar, instead of needing to type it in).
Automated TelNmbr formatting in Current- and Archived-JobRecord Forms.
Option to make automated mileage calculation round-trip or one-way (QET-specific); option to make mileage amount accrue to Merchandise SalesJournal category as opposed to Labor.
When sending emails via the SD-Mail Compose windows, you may now include multiple attachments.
New field, DateOfPendingAppointment, added to JobPerusal form's "Print Summary of Found Items" option.
Option to specify QET-specific Leave-Behind Douments.
Updated Zone-Scheduler Handbook:
Embarrassed to discover this handbook had never been updated to include description (and instructions on how to use) two major augmentations (flowing-pipes and intelligence-augmented-holdbacks). That is now corrected. The handbook may be conveniently accessed via this button:
up in the top-right corner if ServiceDesk's ZonePlanner form (Shift-F5 is the shortcut).
Right-Click to Open ThisCompanyBulletinBoard.rtf:
That cool Bulletin-Board feature that we announced with release of Ver.4.7.130?
Well, by it's nature the content of that Board is something you might want to change with some frequency. So, it should be more convenient than having to manually navigate in your system to find the underlying file.
It should be more convenient, and now it is. Just right-click in the Bulletin Board, and the underlying file will automatically open, ready for editing.
The EmailedDispatchReceiver (EDR) Can Now Process for First-American:
If you don't know, this utility automates reception of dispatches from a number of entities who send their dispatches via email, e.g., AHS, Old Republic, Fidelity National Home Warranty (also formerly did Warrantech and NEW via such means when they still depended on emails). For years, many people asked us to add First American into the capabilities list. But there was a big impediment. First American sends their dispatches in a PDF document that shows only an image of the dispatch text, rather than presenting the dispatch as text itself. It's much tougher to parse text from an image.
Regardless, we finally cracked that nut. Now the EDR can do First American too.
Multi-Select Now Available in SD-Mail:
Many folks don't know about Windows multi-select. Obviously, when you mouse-click on an item in Windows if becomes selected. For example, you click on an item to select it and hit Delete on your keyboard to delete. You can click down on an item and drag some place else to move it. All this is great, but what if you want to do the same action to multiple items at once?
That's where Windows multi-select comes in. It's very simple. If you already have one or more items selected and you want add another particular item (or remove an item from what's already selected), simply to a Ctrl-Click on that. If you want to select a whole range of items, click on the first to select it, then do a Shift-Click on the last.
It's that simple.
Now that you know what multi-select is, you can know what is the meaning of this improvement. You can now do multi-select in your list of SD-Mails:
If you want to delete a bunch of items, for example, select all the ones you want to delete, then click on the Discard button (much faster than doing each individually).
Option to Email Payroll Reports:
Historically, payroll and commission reports have been viewable on-screen, or printable. Now you can email them as well.
New Rossware PDF-Writer:
In a number of contexts, folks have wanted to automate (or at least semi-automate) the process of emailing a PDF document.
An example situation is when emailing a parts-order request to a parts vendor. A PDF document can be configured as a "form" that has all relevant request information, and asks your vendor to fill-in boxes to indicate how he is fulfilling your request (e.g., is he shipping, back-ordering, did he find the part is NLA, etc.). Similarly, you may email a PDF document that works as a status inquiry on prior-ordered parts. Back in the old days (before SD-Mobile) some companies also liked to email their technicians a PDF image of each job-ticket/invoice on the current day's roster -- this worked as their very method of dispatching to their techs, typically with intent that each tech should print the set of tickets via his home computer.
Anyhow, there is a bit of technological hurdle in making these processes occur. In general, it's easy to create a PDF document. You simply install any from among dozens of free PDF "printers." These install like a regular printer driver (the piece of software you install in Windows to control a standard physical printer), but, instead of connecting to a piece of actual hardware (and to produce paper output), their output is instead a PDF file. Thus, when you want to make a PDF document from any Windows application, you simply use its facility to print, then choose an installed PDF printer (from among the standard Windows list of printers, once you have one there) as the target print-to location.
The hurdle exists because you want ServiceDesk to automate creation of an email and you likewise want it to simultaneously attach a PDF file to that email. ServiceDesk can create an email for you just fine. It can send input to a PDF printer just fine. However, it can't attach the file that's produced by the PDF printer to the email unless it knows what file (i.e., location and name) that PDF printer produced. That's the difficulty.
We solved it years ago by finding a particular PDF printer that allows an application (like ServiceDesk) to make a request directly to it, specifically specifying the particular file that it should produce. With this ability, ServiceDesk can direct the PDF printer to create its output with a particular name and location, then find the result there and attach it to your email.
The name of the program we found to do this is pdfFactory. It's maker sells it for $50 per install. Until now, when you first went to do one of the types of emailing that has depended on that product, you'd be prompted to go to the maker's website and download it. Now we fixed that. You don't have to buy pdfFactory any more.
We now provide you with a Rossware-branded PDF printer. We call it the Rossware PDF-Writer, and the right to use it is inclusive to your ServiceDesk purchase and/or support.
From this version forward, instead of being prompted to install pdfFactory when first wanting to initiate a relevant action, you will instead be prompted to download and install the Rossware PDF-Writer (and you'll save $50; yahoo!).
If you already have pdfFactory installed and you want to switch to use of the Rossware PDF-Writer (yes, we do believe it's better), or if you simply wish to install the Rossware PDF-Writer because it's a darned good PDF printer and sometimes you want to print to a PDF document, you may directly download it here.
New PartsProcess Date-Filters
We had a request to be able to filter by appointment date when working in the current-PartsProcess form (aka "F8" form). So, we added it:
The operation is straightforward, but please note items will not show unless they are connected to a job that has a pending appointment (and also, of course, where the date is not excluded by the filter).
Raw-Data XML-Attachments Now Included With DispatchLink-Inserted Dispatches:
It's a common issue. You are using SB-DispatchLink (SBDL), SP-DispatchLink (SPDL), LG-DispatchLink (LGDL) or Samsung-DispatchLink (SSDL). The utility pulls a dispatch from its connected entity and creates a Callsheet for you. You suspect it did not place in all the available information as perfectly as it might have. Perhaps you are able to look in the online data and find stuff there that was not placed in the Callsheet, or perhaps it reads differently than in the Callsheet.
Is it possible that Rossware's utility did not process the data as it should have?
The short answer is yes: certainly, it is possible.
However, it's impossible to know if any apparent fault is in the utility or if it is in such data as the entity (e.g., ServiceBench) handed off to the utility -- unless we are able to see exactly what data was in fact handed off.
That is the purpose of this new feature (i.e., to allow such visibility). From here forward, we are configuring each of the utilities to include a raw-data file that will be a precise copy of such data as was provided by the connecting entity when it handed off the dispatch. Each Callsheet will include a hyperlink reference to its respective file:
A simple double-click on that hyperlink will display the direct, actual data for you:
You may then see and compare, with intent to determine if there was any information provided that our Rossware utility might (if better coded) have been able to handle for you in a more beneficial manner.
If you find yes, you will then be well-equipped to contact us at Rossware. You can show us the actual data, and how our utility did not handle it as beneficially as it might have. We'll then be poised to know exactly what we can do to make it better.
In the alternative, you may find that the underlying entity (e.g., ServiceBench) is not handing off such data as you need to have them hand off. If that is the finding, you and we will then be well-equipped (we often do go to bat for you in situations like this) to go to that entity, and "hold their feet to the fire."
For context, we have always in the past gone through the process of analyzing such underlying data on our own (though sourced from a more difficult to access location), when a a concern has been brought to our attention. This new feature allows you the opportunity to examine it on your own first (it likewise provides us with a much easier source when we wish to examine).
There is a counterpart to all of this. Please don't expect us to invent data that the entity has failed to hand off to us. And please don't expect us to present you with better data than they have handed off to us. This new feature allows you to see precisely what they have handed off (and in each specific instance), so that you can judge for yourself.
As of the date of this release, we have so far only updated SBDL (Ver. 4.8.1) to create the underlying files and connected Callsheet hyperlinks. We'll plan to have the same new feature within each next update of the other utilities. Please note you must update to this 4.8.3 release of ServiceDesk (or higher) for the new style of hyperlink as is involved to function. If you have not done so, the response to double-clicking on any such hyperlink will be a message indicating that the document cannot be found.
Automated Insertion of Mileage-Fee and Quantity in On-Screen Narda Claim:
We owe this one to a new client in Canada (Michael Moncada of Northern Electronic & Appliance Services, Inc.). He explained that he has many contracts with third-parties that specify varying mileage rate schemes, and, absent any method to automate accurate insertion of the correctly-applicable amount in each instance, he would likely end up failing to claim for significant amounts of otherwise collectible sums.
We would not want that to happen.
If with this update you go to your QuickCommonEntries form (Shift-F1) and choose to edit for any entry, you'll see some new boxes:
The obvious concept here is, if you have any QCE client in regard to whom you have an agreed-upon mileage rate, you should use these two new boxes to put in the non-surcharged unit-radius and the rate-per-unit that applies beyond that radius (I use the expression "unit" because it is kilometers that will apply for Canadians, miles for the rest of us).
Equipped with this new information, something new and wonderful will happen anytime you import new information into an on-screen Narda. The system will see the mileage-rate structure you've setup for the underlying client. It will grab the address for the underlying service location and it will grab the address for your service office. It will then make a behind-the-scenes call to a Google API that will rapidly return a driving-distance figure. Based on this driving-distance figure (and your underlying values), the system will look to see if the Google-indicated driving distance exceeds the indicated radius. If so, it will insert to your on-screen Narda like this:
For claims to most entities, we believe this is exactly the fill-in you will need. However, we know that some of the underlying third-parties use the applicable fields differently (i.e., one might expect the mileage-fee to be in one box, while one might expect it to be in another). If you encounter a situation where these insertions need to be configured differently for a particular entity, please let us know and we will alter accordingly.
We do need to provide a little caveat in regard to this release. You might notice that with this release the versioning series has gone from 4.7.x to 4.8.x. We reserve such series changes for instances where there is a significant structural change in one or more underlying files. In this case, to accommodate the two added boxes, we had to alter the structure of the file that contains your QuickCommonEntries data. On first use, the system will automatically build a new QceFile in the new structure (the new filename will be QceFile.4P8 as opposed to the old QceFile.4P3). Each other instance of ServiceDesk will be prompted to close and re-open in updated mode, so as to use the new file. The caveat is this: each of the utilities that also use your QceFile (e.g., SD-MobileLink, SB-DispatchLink, SP-DispatchLink, etc.) will still be using the old file, until you update each to its respective latest release (which, naturally, will cause them to likewise use the new file). What this means, bottom-line, is older copies of those utilities will not see any post-4.8-series changes you make in your QCE data, until and unless they are updated to their own post-change versions.
(FYI, versions of utilities that are updated to use
the new QceFile are SDML Ver. 2.0.54, SBDL Ver. 4.8.0, SPDL Ver. 5.1.0,
LGDL Ver. 2.1.0, SSDL Ver. 2.1.0, EDR Ver. 4.7.0. There is no need
to worry about any such utility-update if you are not actively using
it.)
Terrific New Performance-Testing Tool:
Does it ever feel like your system is running slow? Do you ever feel like you'd like to have an objective measurement, to tell you just how quickly it is or is not performing?
We must confess, our RSS clients (those who lease cloud-hosted servers from us) have sometimes found themselves feeling this way. Sometimes, on investigation, we've concluded the problem is solely because of a slow internet communication on the client side (nothing we can do about that from here). On a number of other occasions, however, we've found there were issues causing slowness right within the systems we provide, and of course those are matters we have had to directly address. Regardless, it has sometimes been difficult to determine which is the case. It's especially difficult when our users are trying to make this determination on their own.
This new tool is designed to let you directly see just how well your system is doing (or ours on your behalf), and regardless of context. It runs a series of processes, and times how long the system takes to perform them. Based on a comparison to some benchmarks, it then gives you an indication of the result.
To run the new tool, navigate via the ServiceDesk MainMenu, as shown here:
The next thing you'll see is this:
.
When you click to run the test, you'll see something like this:
Please note the caption at top indicates actual time as elapsed when performing the test. The blue bar indicates your system's time as a graphic (shorter is better), compared to a typical-fast (but not blazingly-fast) system (green), and as compared to a typically-slow (but not abysmally-slow) system (red). If your result is almost as good or better than typical-fast, you're doing pretty well. If your result is closer to the typical slow, you're not doing so well. If your result is beyond the typical slow, you are doing quite badly.
Please also note that besides the standard (Test functions equally) option as above shown, you may select to Emphasize Disk Access or Emphasize Processor Operations. The general idea is, if your system is slower than it should be, you can try each of the lopsided tests and see if it's more likely one area versus the other that's slowing things down.
We think this will be useful for all users.
Regardless, especially for our RSS users, we suggest you run it when
things are working well, so as to form a benchmark of what to expect.
Then, if it feels like things are running slowly, run it and compare.
Reported results will NOT BE AFFECTED by internet speeds, so this test
can be quite definitive in letting you know if the server systems in
themselves have an issue that needs to be addressed, versus there
potentially being some problem in the communication between them and you
(please note that in some instances there can potentially be a
communication bottleneck at our end, in which case it will still be
incumbent on us to address).
LG-Direct-Claims Now Verified as Fully Functional:
I must sadly confess we were slow to perfect this. We added basic direct-LG claims functionality some while back, but it required real-world testing (and real-world debugging) to truly make it fully succeed. Thanks in significant part to longstanding and patient assistance as provided by Heather Michaelis at J&M Appliance, Inc. (in Redlands, CA), you should find the functionality is now perfect. Thank you Heather!
Option to Exercise Dispatch-Options in Regard to Multiple-Selected Techs:
Everything evolves.
In the ServiceDesk DispatchMap you may do a simple click on a technician's name at the top of his list of appointments. In consequence, you will get a list of many things you may do, in terms or providing him information as connected to that list of jobs:
That list was not always so long. It grew one item at a time as particular persons wanted new options. Then someone wanted something entirely new. It was pointed out that, when you have lots of techs, it takes considerable effort to rotate through each and make the request of what you want in terms of output for each, especially where you want the same output for all of many technicians. We were asked to make an option to request a particular output once, and have it apply to all techs. So, a number years back we did that.
Recently there was a new request. Now it turns out some people want to request a particular output from the above list, and they want it to apply to many of their techs, but not to all of them. So, absent any new facility, the only way to do that has been by individually clicking on each of the particular techs for whom the output is wanted. Again, if you have lots of techs that are involved in the desired output, this can be considerable work.
Hence our new feature.
The longstanding path to get to the dispatch-options list but as applicable to all techs is, when you are in the DispatchMap, use the QuickKey shortcut Alt-P (it's the common Windows 'Print' command). We've now augmented the options you'll get when going there, as follows:
Old "Print" options in DispatchMap | New "Print" options in DispatchMap |
|
|
If you pick the new option, then pick any particular dispatch-options output, you'll be presented with a list of your technicians that looks something like this (though your list of techs may be shorter or longer, depending):
From this list you can use the common Windows multi-select commands to pick the particular set of technicians that you wish to have included in the output. It's that simple.
Option to Initiate Inventory Inquiry from Within Callsheet- and JobRecord ExtraNotes:
The ToolTips that you'll see when floating over with your mousepointer (but in ServiceDesk, not here; what you see here is just an illustration) say it all:
Option to Create a Protected-Partition in Your SalesJournal:
Likely we should have done this one a long time ago.
After you've made any external reliance on entries in your SalesJournal (as when, for example, you've done exports to QuickBooks, filed sales tax liability reports on basis of a SalesSummary Report, etc.), it's important that entries from that period remain as they were when reliance was made. To state it otherwise, you should not change the amounts as involved in entries from such a period.
It does happen, of course, that sometimes you find there were erroneous entries in an earlier period. If that's the case and it's from a period that was externally relied upon, the proper fix is to make a current-period adjusting entry, as opposed to by changing that entry from the past.
Regardless, the design in ServiceDesk has been to rely on you and your staff to be smart in this regard. Needless to say, it has not been a smart element in ServiceDesk.
It is fixed now.
Your SalesRead form (Shift-F3) has a new button:
Just click on it, follow the prompts, and it will do precisely as it says.
If you are wondering, yes, locked-period changes will still be permitted if with use of your MasterPassword. Even then, however, it will be in presence of a dialog that warns appropriately.
Also (and if you are also wondering), yes, there will be an auto-prompt to create the partition each time after you do an export to QuickBooks.
Finally, yes, the ApplicationsJournal also becomes locked per the same Protected-Partition date as you specify for the SalesJournal.
Major Upgrades in Full-Custom Source-of-Business Survey System:
First, let's be explicit in agreeing that it is super-important to have a solid and accurate understanding regarding which marketing investments are having what effect in bringing customers to you. You really need to know this. Where a particular marketing endeavor is producing tremendous "bang for the buck," you likely want to do emphasize that one more. Where another is hardly performing in spite of large cost, you likely want to abandon it. It's critical information.
Since a long time ago, ServiceDesk has had what we sometimes call a "canned" source-of-business survey system (see Chapter 10.G in the ServiceDesk Manual). It's structure is pre-defined, and all you must do to set it up is create the list of yellow-page ads that is applicable to your business at the time you are surveying (yes, it was created when most service companies looked primarily to the yellow pages as their primary source of new COD calls). For the shape of the world in which it was developed, this system provides superb structure and analytics, all pre-built and assembled for you (well, except for your list of yellow-page ads).
But the world changed. Service businesses began using several advertising mechanisms that our "canned" survey system did not contemplate (most especially, of course, the internet). Around eight years ago (see notes under release of Ver. 4.3.94, below), instead of seeking to modify our "canned" system to make it accept every new possible variation and nuance, we decided to build a new system (as an alternative to the still-existing "canned" one) that offers complete, unbridled customizability, and while still permitting a hierarchical query structure (i.e., depending on the answer to one question, it can lead to a different set of sub-questions, and depending on what's answered there, it can lead to another new sub-set, etc.).
Regardless, while robust in its core, this new, Full-Custom Source-Of-Business Survey system has been somewhat bare-bones in terms of what's offered on its periphery. It has not, for example, offered any built-in analytics on survey results, other than just providing you with raw-numbers regarding the quantity of hits in answer to each survey question (and even there it's been an un-augmented Excel spreadsheet that provides such info, which (and at least absent further analysis) is quite less than exciting on its face. Our thinking had been, in exchange for our triumph in having provided you with full and complete flexibility at the core, you may need to perform the final and ultimate analytics on your own.
Recently (upon talking with a client in need), I decided it was long past time for us to finally beef-up this Full-Custom Source-Of-Business Survey system. Here is a list of present improvements:
The Exported Results-Tally Report now includes not just the quantity of hits-in-answer per query. It also includes a figure indicating the amount of revenue earned from jobs which, when surveyed at the outset, resulted in a hit on that answer. To state it more simply, it's now not just quantity that's reported; it's now revenue too.
In regard to both quantity and revenue, the Exported Results-Tally now includes not just raw numbers, but also does some underlying math to provide you with added columns that indicate what is the average per-day rate as applicable to hits on each item (both quantity and revenue) and what is the percent-of-total-overall as attributable to each.
Since results data is now stored in a much improved (more information-dense) manner, it is now possible for you to conduct your survey continuously, yet report on only a particular, date-defined sub-period. (Previously the Exported Results-Tally was inclusive to whatever actual/total period as was included in a particular survey setup.)
Since it now contains six results columns (as compared to the prior just one), the Exported Results-Tally now also has informative column headers, plus an overall header at top indicating the date range included, and other elements of enhanced formatting to make the information more obvious and attractive.
When a CSR has been prompted to conduct the survey (this happens when scheduling a new job) and is mid-way into it, then suddenly realizes that a prior question was answered incorrectly, he/she can now hit Esc to re-start the sequence. He/she can also re-initiate and replace a prior-completed survey, so long as doing so before the Job/Sale transition (just right-click on the Callsheet's Criteria button; this has always been a method to manually initiate the survey queries, if not wanting to otherwise wait for the auto-prompt).
Many businesses receive jobs via automation (whether via SBDL SPDL, LGDL or SSDL), in which case (at least most typically) a CSR will see a Callsheet with appointment info already filled in, and will do the Job-Sale transition without ever having typed into the Callsheet's Appointment box (which is the normal trigger for invoking the survey). Until now, these instances of incoming jobs have escaped the Full-Custom survey. Now they are captured too. Specifically, when a user does the Job-Sale, the system looks to see if a survey was completed. If not, the survey query invokes at that time.
If you choose now to use a .csv alternate as your source definition file, it no longer must be direct-designated in lieu of the more proper .xls instance. It can simply be an added file, while you maintain designation of the .xls instance as your actual source. Each station, if seeing a same-path and otherwise same-name .csv alternate, will use that alternate for the purpose of loading the survey structure for survey-taking purposes. Thus, each station will load much faster, and there is no concern with non-Excel equipped stations being able to load. Even better, there is no need to switch the Settings form based designation back from .csv to .xls when wanting to export a Result-Tally report, because it should simply be set and always stay as a .xls designation there.
There is no longer a concern with different stations "seeing" the source file via different absolute paths. So long as you place your source file in the NetData folder on your server (which, really, is the only logical place), ServiceDesk will behind-the-scenes appropriately interpret that path for each station.
The
applicable mini-manual has also been updated to reflect current
changes. We think you'll find these improvements finally make our
Full-Custom Source-Of-Business Survey system into the super
robust tool that you have wanted and needed.
Direct Claims Transmission for LG:
Most of you enjoy doing direct claims submissions to ServiceBench and ServicePower. There is no need to first save a claim file and then upload it. Instead, ServiceDesk directly uploads the claim for you. Boda bing, boda boom: it's done!
We also had direct claims submissions working with LG between 2008 and 2010. However, in that latter year LG changed to its then-new GSFS system, which lacked the ability to receive direct submissions. Since then, y'all (at least if you are an LG an servicer) have been using the comparatively old-fashioned file-upload system for your LG claims.
Well, now you can be fully modern again.
A little while back, LG finally added ability in its
GSFS system to accept direct claims, and with this release of
ServiceDesk you may employ that ability. Just make the appropriate
pick when going to transmit your claim.
Minor Upgrades in Scheduled-Job-Exports Type 3, 5, 6 and 8:
Formerly, these reports (Alt-F3) had a field to
indicate the amount of revenue received in labor on each job, but not
the amount received for parts and merchandise. That added field is
now included.
Export from the Special Situations Advisory:
The heading says it all. Go to the form
(Alt-F11) and you'll see the new button for this.
New "Bulletin Board" Feature:
Forgive me, but I think a lot of folks are gonna like this one.
Like a lot of things these days, it was not exactly my idea.
Janice Salman called from Just Press One. She runs a call-center with a crew of CSRs, handling calls for a growing number of Rossware clients. She said the quantity has now reached more than 30, and it's getting tough for her CSRs to keep track of the particular details (details that are needed to guide each customer conversation) that vary for each particular client. She wondered if I could suggest a feature in ServiceDesk that, as a ServiceDesk instance comes up for any particular client, would volunteer the particular details of which a CSR needed to be reminded in regard to that client.
Well, I couldn't think of anything existing that seemed to be a super fit.
So, I came up with something, and I think it's a tool that will prove very useful to many of you, whether you have Janice's team taking calls for you or not.
In a nutshell, this is a feature that allows you to add a Notice section (aka "Bulletin Board") to the right of the Callsheets in your standard ServiceDesk interface. Here's is an example of what it might look like:
Of course, I only created a bit of imaginative text, in the above, for the purpose of this illustration. It's solely to provide a notion of some of the kinds of things you might want to do. You could use your Bulletin Board for anything you might like. You can use any color of text you want (or any combination of colors). You can can use any font and any font size. You can use any desired formatting. The general idea is it's a new space, that you can make all yours, and you can change it as often (or as infrequently) as you like.
You might notice, in the above, you can have hyperlinks in your Bulletin Board. If a user simply double-clicks on such a link, the system will immediately open the target. (Please note these must be in the explicit-face-text, SD-Link-acceptable format; embedded hyperlinks will not work in this context or in any other direct-within-ServiceDesk context.)
To implement this new feature is easy.
To start, open a text editor that is capable of saving in .rtf format (stands for RichTextFormat). WordPad is a good choice, and it's automatically present in every Windows computer. Compose the text that you want, and format it in whatever manner you want (i.e., color of text as wanted, type of font, font size, underlining, bold, italics, etc.). Then save your document in a particular name, in a particular file-format, and to a particular location. Specifically save to the sd\netdata folder on your server, in .rtf format (happily that is the native-save format for WordPad), and with this filename:
ThisCompanyBulletinBoard.rtf
That's all you must do.
ServiceDesk will see the file there, will expand on its right-side to show your composed text, and will show it. It's that simple!
Of course, any time you want to change what's shown in the Bulletin Board, just open the file again, make any edits you want, and save. Again, it's that simple. If you decide you do not want to have a Bulletin Board displayed any more, delete the file, and ServiceDesk will respond.
A few notes:
If any user's desktop window does not have sufficient width for the expanded view, that user will of course not be able to see the expanded view.
After you've added the file, deleted it or otherwise changed it, it may take up to one minute before ServiceDesk sees the change and adapts its view accordingly (the reason is it only checks for such changes on a once-per-minute basis).
As you may note in the illustration, the general background color in the Bulletin Board will be configured to display in the same color as you've picked for ServiceDesk itself. So as to assure your text is readily visible, please be sure to pick font colors that are a good contrast with whatever you have picked for that background. It's true that from within your text editor (WordPad or similar) you may potentially pick a particular font-background color for particular text, but for most purposes that tends to look less elegant and read less well (i.e., as compared to a transparent background).
Regardless of as just stated, it may sometimes be
beneficial to selectively pick other-than-transparent
font-background colors. One purpose, for example, could be
found in the fact WordPad (if that's the text editor you are using)
insists on automatically adding standardized hyperlink formatting to
any url that's typed. In other words, it underlines the text
and makes it blue (as in
IAmHyperlinkFormatted). As you can see in our first
illustration some distance above, this blue color may be a poor
contrast from your background. A sensible solution (at least
in this particular circumstance) could be to change the
font-background color on this particular text to something
non-transparent and contrasting, such as you see done here.
You'll likely notice that, in addition to adding a font-background
color for the hyperlink, I also spiffed up some other formatting
elements, as compared to the first example. Basically,
you are similarly in control of formatting -- in terms simply of how
you set it up from within WordPad (or similar), and in terms of what
will ultimately fit within the canvass provided (if you're putting
in a lot or of large text, you'll have to simply see by trial and
error whether it fits in the space we've provided for you).
We hope you'll love this feature. Please let us know.
Improved
Auto-Formatting of Claims for AIG/ServiceNet:
Recently it came to our attention that claim submissions to ServicePower with AIG as the expected-to-pay party were being rejected, owing to absence of indication as to whether it was a "sealed-system" repair versus a normal repair. Upon inquiring with ServicePower, we learned the expectation on AIG claims is for a particular field in their claim format (specifically, it's the field they title "EIA or MFG Repair/Fault/Defect Code 1" to be populated with the code "8002" to denote that it's a sealed system repair, or "8001" to denote that it's a normal repair (why they do not tell us these things in advance is anyone's guess).
Anyhow, with knowledge of this expectation, any of y'all could have made your AIG claims sail through just fine, simply by typing that "8001" or "8002" code into the particular box of our on-screen NARDA, as needed, before transmitting your claim. To be clear, it is this yellow-highlighted box (as shown with assistance of the Translation-ToolTips) that, on ServicePower-formatted claims, is translated into that particular ServicePower field:
Regardless, rather than putting you to the trouble of having to type, we'd much prefer to automate. So, we've now coded so that if you check the on-screen NARDA's dedicated "Sealed System Repair" checkbox, as shown with yellow-highlighting here:
. . . and if it's on a claim being submitted to
ServicePower, with AIG or ServiceNet configured in the underling
JobRecord as the paying party (and if you have not otherwise placed any
text of your own into that box) -- if all that is true -- ServiceDesk
will behind the scenes populate the needed claim field with the needed
"8002" code. Correspondingly, if that "Sealed System Repair"
checkbox is not checked (but the other factors all remain true),
ServiceDesk will behind-the-scenes populate the needed claim field with
the needed "8001" code. It should make successful submission of
these claims into being once again a simple matter.
Flip-Flop and QET-Insertions Now Available Within Archived-JobRecords:
Ken Owen from Service Care in Birmingham, AL pointed to the need for this. It arises, he said, when it's discovered days or weeks after the job was prior completed and "put-to-bed" that the wrong party was claimed against. Perhaps you claimed against Lowes, for example, and now it turns out you need to claim against Whirlpool. When you need to flip the party-info sections around and/or do a QET-insertion within a current job, it's simple. But those automation facilities were not formerly available in the Archived-JobRecord context. Now they are.
SMS (aka "Text-Messaging") Now available as Alternate to Emails and/or RoboCalls (Specifically, for Appointment-Reminder/Confirmation-Requests):
Folks have wanted this for a while. On the surface, one might think adding SMS (stands for "short-messaging-service") would be easy. It was not, but (and regardless) we've done it.
In the next few months we plan to add text-messaging options in several other contexts. For now, it's available in the context of sending out appointment-reminder/confirmation-requests (as an alternate/supplement to emails and/or robo-calls).
In addition to adding the option itself, we also enhanced your control in regard to determining which particular telephone numbers will be the target for robo-calling and/or text-messaging, and over which (of potentially multiple) email addresses may be the target for automated emailing. In fact, we've given you a number of new options in how to scheme such control, with intent that you may pick the particular scheme that best suits your operation.
For detailed instruction on how to use these new schemes (and, indeed, how to implement text-messaging in general), you may click here. In the alternative, from within ServiceDesk you may go to the Settings form (Ctrl-F1 is the shortcut), and there click on the button as shown here:
That will yield this interface, and if you click on the indicated button it will open the same instruction document as above referenced (that button as present within ServiceDesk will be a more handy link when you later want to reference the same instruction document):
Please note that text-messaging requires subscription to SD-CyberOffice, and there is a fee of 5 cents for each SMS.
As one other note, if implementing text-messaging from
ServiceDesk you'll also need to assure you are updated to SD-CyberLink
Ver. 4.5.52 or above. The reason is because some of your
text-message recipients may very well choose to reply via text.
It's only SD-CyberLink Ver. 4.5.52 or above that's equipped to detect
those replies, and to convert them into SD-Mails.
Durable Indication of Whether Each Appointment Was Customer-Confirmed:
Our appointment-reminder/confirmation system has long had a wonderful benefit: you can walk into your office in the morning and, with a quick glance in your DispatchMap, have instant visibility regarding which appointments have been customer-confirmed, and which have not (it's then a simple task to manually call the minority who have not, in the effort to verify if it makes sense to go ahead and send the technician).
At least the above works generally.
However, if you happen to have techs that open their SD-Mobile applications before you've made this review, the little hyphen symbol that indicates confirmation ("-") will be replaced with a check-mark that indicates the technician has received the job. So (and at least for quick, on-it-face review purposes), the confirmation information is lost (it's still present in each narrative JobHistory, but that's less immediately obvious).
We now have a solution for this potential loss (and it's why in the title to this section we use the word "Durable").
It's in a new, toggle-to-optional-display-mode feature in the DispatchMap. From within the DispatchMap, simply hit "F" on your keyboard (we'd like to have used "C" for "show-Confirmed", but the "C"-toggle was already in use, so please think of it as the "F"-toggle for "show-conFirmed") (hit "F" again or Esc to toggle back to normal). In consequence of using this toggle, all the normal check-statuses will disappear, and a new and bolder symbol (specifically, a bold dot) will show to distinguish confirmed appointments from non-confirmed ones. Here is an example:
This showing will endure (and hence be "durable") even if the normal/standard check status has been changed to something else.
This feature also requires that you update SD-CyberLink to Ver. 4.5.52 or above, for it's only that version and later that are equipped to set a new (and durable) behind-the-scenes field with notice of the customer's confirmation (it also means that if you're looking at appointments whose confirmations were processed via older copies of SD-CyberLink, the durable indication will not be there).
If, BTW, you forget the key for this toggle, it's been added to the DispatchMap's "CheatSheet" (right-click in any otherwise non-operative DispatchMap space to display):
So just check there.
Improved Legend-Key
in DispatchMap:
This shows what's meant here:
Old | New |
![]() |
![]() |
To see the DispatchMap's legend key, the toggle is "K".
Easier Embedding of Kudos to Your Website:
In March I sent an email to y'all announcing a really fantastic new feature.
Creation of this feature stemmed from a conundrum all servicers face. You work like the dickens to make your customers happy, and succeed grandly 99 times out of a hundred. However, happy customers seldom post online reviews. On the other hand, unhappy customers (those 1 out of 100, or fewer) very often post online reviews. The result is, on the basis of any new prospect checking online reviews as basis to judge your company, you end up looking much less awesome than you really are.
Our new Kudos system was created as a means to solve this.
It's an outgrowth of the fact our CyberOffice survey system was already auto-generating a very large quantity of supremely superlative comments from your customers (well, at least it's been doing so if you are using this survey system; if you are not, you should be). These praising comments have been great for the ego of our users, but had not formerly been harnessed for their enormous value otherwise.
Now they can be.
Specifically, you can add elements into your website that automatically display real praising comments from your actual customers. These comments are dynamic, forever and automatically updated, showing with live and recent dates. As such, they make a "sale" to any browsing prospect (assuring you are the company they should select for service) like you'd not believe.
Our metrics indicate companies that have implemented such displays are approximately doubling their online-generated business!
So, finally, you can turn-around the online, review-presented picture that prospects get of you. Finally, you can make real and direct use of all those praises that were formerly going unused. It's awesome.
Regardless, there had formerly been a little impediment for some. To embed this new presentation into your website required use of a technology called PHP. Some web development environments do not make it easy to work directly with PHP. So, the main thing that's new in regard to this post is the fact that, as of now, you can use a different (and much easier-to-embed) technology called JavaScript.
For full instructions on how to embed this great feature in your website, click here.
Like other CyberOffice functions, this one too has a moderate fee schedule attached, details here.
Upgraded DispatchMap:
Better Speed
Some Rossware users have DispatchMaps that are big, covering huge expanses of territory. They also have scores of technicians, meaning there are hundreds of appointments within any given day's schedule. Given the traditional method as used by the underlying machinery for creating any new view position (as you "pan" your view Up, Left, Down or Right), these large elements have sometimes resulted in slower than instant "re-painting" with each such panning change. It was potentially even worse for those using a centralized server (such as involved with Rossware's "RSS" cloud-server hosting), because in that situation all the imagery processing is done by a single machine, whose resources are shared among multiple users. These delays are not something most users have experienced, but, for those few who have, it's not fun when you want to move from the bottom of your Map to the top (or vice versa), and must wait a second or so between each movement.
This issue is now solved!
We've created an entirely new behind-the-scenes methodology that, for those who've experienced such delays, should entirely eliminate them. Indeed, whatever was the speed of "panning" that you prior experienced, it's guaranteed to now be faster. It's possible (if your prior speed created zero perception of delay, which was indeed the typical scenario) you will not notice the difference, but the fact is acceleration will be there.
Mouse-Drag Panning
In conjunction with the above-described speed-improvement, we have taken occasion (coterminous with the same work) to upgrade a few other DispatchMap elements.
Most notably, you may now do something within the DispatchMap you have likely found yourself intuitively wanting to do -- and feeling like you should be able to do. Specifically, you may click down with your mouse and drag your viewing position in any direction wanted. Try it. You'll like it.
Improved Screen-Size Adaptation
Additionally, we have refined the DispatchMap's ability to intelligently adapt to larger screen sizes.
As background, several years ago we often had trouble persuading new users to upgrade their screens to the minimum screen-size that ServiceDesk demands (which is 1024 X 768 pixels, aka "XGA"). Gradually, typical screen sizes began growing larger. When we realized that a significant quantity of users finally had screen sizes larger than than the XGA minimum, we further realized it would be beneficial if the DispatchMap expanded to take advantage of such larger-available screen space.
That's been a feature for a long time now (i.e., ServiceDesk expands, to potentially fill your screen, when moving into the DispatchMap). However, the expansion was not in every instance seamless. A complicating factor is that we design your Map with panning positions that assume an XGA-size display. When your actual view window is bigger, one or more such panning positions may no longer make sense. Earlier we'd programmed a somewhat clumsy adaptation for this. The present adaptation is much improved.
When doing this improvement, BTW, it occurred to us we might do still more. The present expansion scheme allows an expansion up to, potentially, the full size of the particular screen (where you have multiple screens) in which ServiceDesk is running. It occurred to us some users (particularly those with very large maps, who also use multiple screens) might enjoy an expansion that takes advantage of multiple screens (i.e., will expand, if needed, across more than one). We have not at this point done such coding as would be needed to make this happen, but are curious as to whether it's something some of y'all out there might like? If so, please let us know.
New Report: Office-Person's Productivity:
Over the years, ServiceDesk has grown to be pretty darn strong in regard to providing you with a large basket of superb analytics (aka "metrics"). You may, for example, examine a plethora of attributes regarding technician performance, or analyze a variety of measures concerning company performance and profitability. There are even methods for assessing burdens as compared to profitability between and among your various High-Volume-Clients.
Many years ago, ServiceDesk did not have so much strength in the analytics area. This strength has grown gradually, as users have demanded better insight into particular areas of visibility, and we have built in response.
Regardless, one area of analytics has remained sorely limited -- notwithstanding that at least one client has repeatedly asked for this particular hole to be filled. I feel terrible that I kept failing to find my way toward creating the new report he so much wanted, and first asked for (I believe) well more than two years ago. Anyhow, I committed to myself that I'd no longer permit other matters get in the way of this . . . and, Eureka, I've now done it.
The prior neglected area involves assessment of productivity between and among office personnel.
To be clear, there were some prior measurement methods available. The Result-on-Dispatches Report, for example (F11-->T-->D), shows (among many other things) the quantity of jobs originated by each office person, along with the quantities and percentages that led to first-time-completions, completions otherwise, parts-ordered, no-shows, etc. The ScheduleJobsReport (Alt/F3-->J) creates an export from which you can direct-mine for a plethora of details regarding jobs as created by each office person.
Regardless, these prior sources did not directly measure the quantity of a great many other actions that office persons are typically involved in. Our new report does.
This new report finds its home in the Reports form, which is QuickKey-accessed by striking F11:
It runs much like other reports in this venue, and when complete will display something akin to this (depending of course on your own data and instruction parameters):
As you can see is suggested by the sub-title, this report uses JobHistory notes to compile a tally of events as managed by each office person.
To get an idea of how a report like this might be gleaned for information, just take a look. At a glance in the first column, you can see that "JG" was most productive in creating new jobs, while "ML" was considerably more productive in creating appointments outside of initial job creation (just look for the largest numbers as seen in the first two columns, above). "ML" was also big on managing appointment changes. Going on the down line, you can compare productivity in several other areas. "JJ," for example, was the largest actor in managing PartsProcess (special-order parts) activities, and "LB" was just barely behind. In the farthest right "Totals" column, you can readily see that "LB" participated in the greatest quantity of actions overall (at least in terms of what we are managing to measure here).
You may notice there are two groups of listed office persons, with a gap in-between. Basically, those in the first group are pulled from your current-at-the-moment "office-persons-roster" as maintained in your ServiceDesk Settings form. Those in the second group involve note entries with other office-person abbreviations (i.e., ones that are no longer found in your current roster).
Like most of the reports in the F11 venue, this one too has been built with a "Checking-Data Export." Basically, once the report displays, there is a new button within the lower-right of the form:
Click on that button, and the system will create an export that explicitly shows the data it relied upon in compiling the analysis for you. This can be very useful if you are seeking to verify integrity in the numbers, or just better understand what stands behind them. It also can enable you to do your own different kinds of analysis, directly on top of what is contained within the export. Here's a section of export as created from the above report:
As you can see, it lists each note that it pulled from JobRecords as applicable to the report period (it's the note itself that must fit within the date range, not the JobRecord), and indicates what kind of action it judged the note to involve, and which person was involved (a blank in those columns indicates the system did not deduce any tally-able action on basis of the note).
Try the new report. We think you'll like it!
Miscellaneous:
Upgraded LG-DispatchLink to optionally upload narrative history. Also, restored code regarding availability uploads to do math trick with LG-reckoned burdens (undoing change as made 5/25).
Made it so change of a UIS as attached and navigated to from JobRecord re-flags any pending appointment as needed new upload.
Made it so you can right-click on a Callsheet's Criteria button to invoke a SourceOfBusiness survey.
Added function for auto-add to PartsHotList when
s/o item is marked MvdToStk.
Made it so spec-tagging a part and checking in a
s/o part re-flag an appointment for upload.
Fixed fact that when click in archived JobRecord history and it occludes AfterNotes, then release, the controls on the AfterNotes did not reappear.
Changed calls from DispatchMap to Bing and Google to use "https" instead
of just "http".
Added filter in ResultOnDispatches report that causes it to exclude ShopJobs.
New A/R Search:
We'll give credit for this one to Jackie at Landers Appliance. The impetus is Whirlpool's new method for honoring replacement-parts-warranty. I'm referring to the arrangement where, instead of giving you credit when having purchased a replacement for a failed-and-formerly-replaced-part, the vendor instead gives you a new part. Jackie's business makes an A/R to manage the expectation for these replacements (much as they would an expectation for money credit). Yet, when her company's main vendor ships the replacement, they do so with absolutely no reference to the particular job (or "claim") it is associated with. Thus, it's tough to match the incoming part with the particular A/R that was setup to assure it is received.
The solution we came up with is:
I have just added a new search function in the Accounts-Receivable form (F3). It allows you to do a search (and for any string of characters) in the Notes section as applicable to your entire set of A/Rs.
Jackie will make it a practice, when creating the special A/Rs that are for this described purpose, to put the partnumber (which is expected to be received back) into the notes of each such A/R.
When a part arrives that is involved in this replacement-parts-warranty situation, she'll use the new search feature, to thereby locate the A/R that's applicable to that part.
Here's what it looks like:
Of course, you can use this new search to look for an A/R containing any string of text of any kind. It does not have to be a part number you are seeking there.
New All-Appointments Display in
DispatchMap:
Credit for this one goes to Brenda at Saginaw Valley Appliance. Brenda said her company gets a lot of cancellations, which opens near-term vacancies they are anxious to fill. She said they indeed use the DispatchMap's longstanding "Show-Jobs-Needing-Scheduled" feature, which is intended (in part) to help fulfill this need (it's the one that shows orange "pumpkins" as location-references for jobs that need scheduled, and green pumpkins for any appointments that are further out than the displayed date and which have been marked to indicate the customer "wants-sooner"). But, she said, they often can't find suitable jobs (as needed to fill holes) via this category of display. In consequence, they find themselves going through just ordinary appointments that are scheduled for further into the future, to see if any can be moved up, so as to fill near-term holes. She said this is somewhat laborious, and asked for an easier method by which to rapidly and instantly see all those further-in-the-future appointments.
So, we made the new feature. Here's the reference to it in the DispatchMap's Cheat-Sheet (right-click on any empty location on the DispatchMap to see its Cheat-Sheet):
So, the general idea is, when you select this option, you'll see the same set of orange and green "pumpkins" that display with the old and longstanding option that's listed just above it. However, you'll also see blue pumpkins (yes, blue) to signify the location of each other appointment that's currently pending, but for dates other than the actual displayed date. It is thus now possible to see your entire appointment roster in a single graphic display.
As with the other "pumpkins," a simple click will of course open the underlying JobRecord.
Improved Visibility into Spec-Tagged Items:
Now we answer to Mark at Convenient Appliance Service. Mark called to say he needed better visibility regarding what inventory items are spec-tagged, both from the inventory-management perspective and from the perspective of Job-Management (i.e., when looking at a JobRecord, there should be an easy means to see what's presently spec-tagged to it).
So, we've done two things.
First, the InventoryControl form (F10) has a new display option:
This new option will list every inventory item that has a current spec tag. Thus, there is no longer need to peruse through the raw-View, as there was in the past.
Secondarily, we added a new link-to-show function in the JobRecord form (F7). Reminder regarding availability of this function (and of its method) is obtained when you float your mousepointer over this form's "Tag-Part-for-Visit" button:
So, just as the ToolTip suggests, do a right-click if you want to see inventory items as presently tagged for that job. In result, the system will open your InventoryControl form, configured to show the new display (as described in the entry just above this one), but poised to list only such items as apply to the job from which you linked.
Show-and-Link Regarding Underlying HighVolumeClient in A/R-Aging/Breakdown-by-HVC Report:
This one was to fulfill a request from Ian at The Appliance Guru. He said his company has a very large quantity of clients who are setup in the HVC category -- so many that, on reviewing A/R-aging with breakdown by HVC (the sequence to obtain this report is F11-->A-->B), it's not possible to recognize each such company based on the mere abbreviation alone.
In solution, we now display a ToolTip over each/any HVC line-item in this report, as you float your mousepointer over it. The ToolTip provides the full name of the underlying HighVolumeClient:
While doing this, it occurred to me that, additionally, you might want to do a quick-link to the underlying QuickEntryTemplate, as applicable to any HVC line-item you are looking at (suppose, for example, you see one with that's got too many A/Rs that are too old, and you want to look at that company's QET to review elements of your arrangements and contact-info with them). If you simply click on any HVC line-item in this report, it instantly opens that underlying QET for you.
(If you are wondering, BTW, why displayed A/R ages in the above report are so very old, it's because it's data from my old service company, which was sold many years ago.)
Miscellaneous:
Every release contains numerous small improvements and fixes. Usually, they are either sufficiently small or technical so as to warrant no description in this particular blog. However, there a few small items in this release we should at least briefly mention:
There is now an export of FundsJournal Entries (in the F9 form, use standard functions to filter for display, click on the Print/Export button, then choose export as opposed to printing).
In the InventoryControl form, the "Find-Qty-and-Loc's-of-Specific-Item" report (accessed via F10-->I-->F) is now scrollable, as needed for companies that have more than 30 technicians. (Also improved showing and scrollability in the Tabulate-Values report.)
Changed the warning about the SD-Mail folder having too many items in it. Now it will allow a great many more items to accumulate, before warning you there are too many.
New Integrations with External Mapping Tools (Open-Route-in-Bing
and Optimize-Sequence-via-Google):
At Rossware, we are continually striving to reach an elusive target: providing the most perfect-possible system for every user. Even in a static world, this would be a tough goal to fully reach. But it's tougher still because the world is not static. Suppose, against all odds, on one magic day we actually achieved our goal. The next day, we'd again be short, because overnight the world would have changed.
Everyone of you, our users, is continually facing new sets of operating dynamics as significant to your business. The computing environment is likewise (and in and of itself) constantly changing (new operating systems, new communication modes, etc.), and the set of potentially connecting tools and entities (to which our systems can interrelate and otherwise integrate) are changing too.
In particular regard to new capabilities as offered in this release, we've long had two external-map-utility integrations that many were enjoying, when suddenly both became less available (or at least less useful) than before.
First, we've long had a method where ServiceDesk will compile the list of stops that you have planned for a technician on any given day, and direct-pass to MapPoint's routing optimization engine. MapPoint churns through the set of addresses. Accounting for road layouts and even traffic patterns, it deduces a sequence of stops that will minimize driving time. It spits the result back, and ServiceDesk sequences the tech's stops accordingly. Many have loved this feature, in spite of the fact that, to use it, you must purchase and install MapPoint. Sadly, as of January this year that purchase was no longer an option. Microsoft stopped selling MapPoint.
Second, many have likewise enjoyed using the feature where, by simple action in the DispatchMap, you may open a technician's route in either MapPoint or in GoogleMaps. More have enjoyed the latter because GoogleMaps is free, and is available absent any separate install. About a year ago, however, GoogleMaps changed its interface to one that most of our users found less helpful for multi-stop route-analysis (often the reaction was to blame us here at Rossware for this change; honestly, we were not responsible for it). Until very recently, there was an easy solution in that GoogleMaps would permit you to revert to their "Classic" view. Recently, however, GoogleMaps removed that option
So, at Rossware, we faced the conundrum where two valuable, system-integrated tools were suddenly less available (or less helpful) than before. We needed to find new tools with which to integrate that would be, hopefully, as good or better than the old ones. In this release, we have done precisely that.
In regard to using an automated routing-sequence-optimization engine, we found a superb MapPoint replacement in an online service provided by Google. At least so far this service is free (which is obviously better than MapPoint), and it even returns its optimized solutions more quickly than does MapPoint.
In regard to opening a technician's route in an online mapping resource that has the same benefits as the old GoogleMaps, we found a superb replacement in Bing Maps.
To give you easy access to these new options, we also had to modify the applicable menu and Key-Mouse paths.
For automated routing-sequence-optimization, you may continue to use the same Key-Mouse action as was formerly dedicated solely to MapPoint optimization. That action is still (but now somewhat differently) described in the DispatchMap's CheatSheet:
Old Description from DispatchMap CheatSheet | New Description of Path (right-click in any non-functional spot of the DispatchMap to get this CheatSheet) |
|
|
Since this Key-Mouse action now gives you multiple options (we have retained the old options for those who still wish to use them), instead of immediately doing the optimization via MapPoint, as before, it will now take you to a new, "Link-to-External-Map-Resources" options list, where you may pick the particular action desired:
If wanting the new optimization, for example, you'd pick "G" from the above. If wanting the old MapPoint optimization, you'd pick "M."
The old path for opening a tech's route in an external map was by clicking on a tech's name at the top of his list, then picking from what was beginning to become a very long list of options there. Rather than making this particular options list even longer still (i.e., via direct addition of yet another new option), we instead removed the old and multiple "Open Route in . . . " set of options, and replaced with a single option that, like the Key-Mouse action above-described, opens that same new "Link-to-External-Map-Resources" options list:
Old list of options as obtained when clicking on a tech's name at the top of his list | The now-simplified list of options |
|
|
So, there are now two paths to this newly-expanded (and now brought together in one place) set of options. You may use the Cheat-Sheet indicated Key-Mouse action (Shft/Ctrl-Click on either the tech's name or on any in-location-show appointment reference), or you may do a simple-click on a tech's name at the top of his list, then pick "Q" per the right-side image above.
For those who hated the change as made in GoogleMaps, we think you'll love using Bing Maps instead. For those who loved the automated routing-sequence-optimization, we think you'll find Google's engine is very effective.
It is ironic, perhaps, that we are now providing an alternative to Google as an online source for map-opening a tech's route, while newly embracing a different arm of Google for routing-sequence-automation. C'est la vie!
If you are wondering, BTW, yes, the open-route-in-Bing option has indeed also been added within SD-Mobile/w (i.e., the Windows version). We'll also add it to SD-Mobile/i (that's the iPad version) as soon as we are able.
New Option for POS-Insertions List:
We've had many clients who, in the POS environment, wanted ability to insert line-items to POS tickets, but as pulled from other-than the inventory system's MasterPartsPlan, SmartParts listings (as typically applicable to special-order parts) or to serialized inventory as pulled from the SD-Dealer setup (these are the three pull/line-item-insertions that have formerly been available).
So, we've now added this ability.
You may make a custom list of the particular insertion options you want want to have for your setup. Your list will need to have four columns. The first is an item identifier (roughly equivalent to a partnumber), and will (when selected from the POS context) be inserted to the partnumber column in the POS ticket. The second is for item description, and will be inserted (obviously) in the description box. The third is for price, and will (again, obviously) be inserted to the POS form's price box. The fourth column is for an indication if the item is to be deemed as non-taxable. If yes, you should simply place within this column/box the expression "NO TAX".
Once you've made your list (and as above-described), save it in comma-delimited format as PosInsertionsList.csv. Save to the \sd\netdata folder on your server. ServiceDesk will see your file there, and then make use of it.
Specifically, you'll see a new option come up (this option will be activated only is ServiceDesk sees the indicated file) when clicking into the partnumber box in any POS line-item:
Pick this new option, and your dropdown insertions option will be pulled from the list you have created. If you pick an option for which "NO TAX" was designated (and assuming you've picked one of the FinishedForms that includes the line-item-based tax-exempt checkboxes), that line-item will automatically so check for you.
New Management Tool: Quick-View on Callsheet Status:
You've likely recognized that the caption bar at the top of ServiceDesk has an alternating display to let you know if you have Callsheets needing attention, past-due for attention, the quantity and so on. But, they only show you an indication of such Callsheets as are applicable to you. If you are a manager, you might want to know such indications as applicable to your entire staff, as a group. This new tool is for that purpose.
Specifically, if you float your mousepointer at the "four-corners" intersection just between where all four Callsheets meet . . .
. . . the caption bar at top will momentarily change to give you a system-wide synopsis on the status of all pending Callsheets.
Option to Use Half-Hour Increments in Auto-Time-Frame-Estimator:
Our DispatchMap (F5) has long had a tool that will create a series of time-frames for each appointment as assigned to a tech, based on parameters you provide (Ctrl-Click on the tech's name at the top of his list).
Until now, the time-frames as inserted have been in whole-hour increments only (i.e., if your parameters would have otherwise made for sub-hour increments, the system would simply round to the nearest whole hour). Now there is an option to have it round to the nearest half-hour instead. To invoke the option, bring up your DispatchMap's CheatSheet (right-click in any non-operative space), and pick this option:
In result, we are now able to produce something like this:
Whereas, before, you would have seen nearest whole-hours only.
Augmented Intelligence when Using Option to MakeVacationEntries:
In the ScheduleList form (F6) there has long been an option to create
multiple "Unvlbl" type entries in one action, as particularly applicable
where a tech will be on vacation for multiple days. Until now, the
Job-Count value for these entries has defaulted at 8. Now, the
system will look to your Technician-Properties setup for the technician
involved (Settings form, click on the tech of interest).
Specifically, it will look to see what you have set as the maximum
JobCount value that this tech can handle in a day. If you have set
a value there, it will insert that particular value for these entries,
as opposed to the default of 8.
QuickLinks to ApplianceVideo.com's "How
to Replace this Part" videos:
Among Rossware clients are many ambitious, creative and ingenious people (if you wish to know, we're pretty proud to be serving such a bunch).
Anyway, Matt Janoweicki and his team at Ace Appliance (Toledo, OH) began a few years ago in building a treasure trove of extremely professional videos, each showing the complete sequence of steps as involved in replacing a particular part. They put the whole trove online (and it continues to be fast-growing) in a website called appliancevideo.com, and are now making a serious business out of the enterprise.
Recently, Matt and his team asked if Rossware might be interested in making some integrated ties into those videos. It seemed like a good idea, and so now has been done.
In fact, it's been done for both ServiceDesk and SD-Mobile.
The link from within ServiceDesk is via the PartsProcess form (F8). To open the "how to" video as connected with any part number, just do a Alt/right-click on that part number:
That action will immediately query the appliancevideo.com website for any videos it has as associated with that part number. The website will display with any such videos selected.
If you forget the above-described mouse/key action, don't worry. It's another of the tricks that's described in the contextual "cheat-sheet:"
As in the case of other contextual cheat-sheets, it's accessed by right-clicking in any otherwise non-operative portion of the form (e.g., for the F8 form it's easiest to right-click in the colorful label area at top).
For information about how to use the new link from within SD-Mobile, refer to the SD-Mobile WorkDiary.
Auto-Grey-Toggling in PartsPick Form:
The PartsPick form (Ctrl-Shift/F8) was designed as an onscreen venue where you easily see each item that needs moved to/from a tech, and check-off such movements as have actually occurred.
It's a very powerful tool, and we designed with a philosophy engineered toward enforcing conscientiousness in the user. In other words, we did not want users to simply look at the surface of items for which movement was expected, check-off whatever was moved, and ignore everything else. We wanted to assure users stayed really on top of the whole list of expectations, paying due attention to each and every item.
To achieve this purpose, we made it so each item of expected movement must be toggled in each session. Specifically, it must be toggled to red (to indicate movement is indeed occurring) or to grey (to indicate that item is being deliberately left as-is for the time-being).
Overall, that's a good purpose, but some users routinely were in a situation where the system expected a large list of items back from the tech, which they were deliberately leaving with the tech pending an expected (but not yet scheduled) future appointment. It was rather a nuisance to have to manually toggle-to-grey each of these items, each time, before any other movements could be registered. So, we added an option. It's referenced in the text when you click on the "Record Movements" button, but without all items toggled as per expectation. Historically, that click would produce a message that simply told you you must toggle all items. Now, it adds a little paragraph:
That added paragraph is there to guide you to the newly-added option. Follow it's prescription, and you'll see this:
If you choose the first option, obviously, you'll get the result it promises.
Upgraded SD-Mail:
I'll tell you a story.
When I first created the SD-Mail system, it was before regular internet email had become the mainstream feature and practice it's now been for the last . . . well . . . almost 20 years. I'd seen a movie in which a within-business electronic mail system featured prominently (1994's "Disclosure," with Michael Douglas and Demi Moore); I thought the feature looked cool and useful, so I immediately wrote a similar one into ServiceDesk. Though the feature was indeed cool, it was a very short time later when regular internet email began to go very much mainstream, and its capabilities were far more robust. Given this, I assumed that any usage for my system would quickly go by the wayside, as folks moved to usage of full internet email instead.
I was wrong.
It turns out, to this very day, most Rossware clients use SD-Mail like crazy. And, since SD-Mobile was introduced (with inclusion of its own tie-in to SD-Mail), they use it even more, for communication to and from techs. I am gratified, for it's nice, when you've invested to build a tool, to see that not only is it heartily used, but its usage endures.
Regardless, over all these many years our simple SD-Mail system has never been upgraded. Really, within ServiceDesk, it has persisted in a state that's all but identical to my original creation. The only real advance was extending it into SD-Mobile, and there's an interesting twist on that. When I built SD-Mobile's own SD-Mail interface, I made it far more modern and capable. Since then, ServiceDesk itself has lagged far behind SD-Mobile in regard to SD-Mail, and it was ServiceDesk that needed to catch up.
This release accomplishes that.
In fact, we've taken essentially the same SD-Mail interface as has prior existed in SD-Mobile, and have now built the same into ServiceDesk. It looks like this.
Likely, you will immediately see this interface looks much more modern and capable. And it is. No longer are you limited to seriatim (PgUp and PgDn) rotations among your 'In' items (instead you can direct click to look at any item of interest, and in any order). No longer must you choose between leaving an item in your 'In' box, versus tossing it entirely (since there is now a 'Saved Items' folder into which you can move it). No longer must you complete and send an outgoing email before leaving your current session, else lose it and have to begin again (since you can also save these, as drafts, to your 'Saved Items' folder). No longer must you manually type in your Send-To targets (since you may now click from selections in a dropdown). Regardless, you still have the option to type-in a target if that's your preference (many of us keyboard-centric people prefer the speed that is maintained when keeping our fingers on the keyboard); you can even tab right back into the recipients box if making a list of multiple recipients (i.e., type G→R→Tab→D→S→Tab→A→M if sending a mail to Glade Ross, Dave Somer and Art Manoogian).
Besides these user-interface improvements, there are a plethora of others behind the scenes. For example, the entire and underlying folder structure has been improved. Instead of each user's mails sharing the same \sd\Email folder space, for example, each user now gets his/her own folders, along with 'In' and 'Saved' subfolders too. It's much better organization, and will produce improved operating efficiency. Additionally, the email copies that are placed in the \sd\OldMail folder will now on-their-face indicate sending and receiving parties.
Overall, we think you are going to like this improved SD-Mail system much better.
There is one caveat. It applies only if you're using SD-Mobile. Because this system puts outgoing emails in a new subfolder (and in a newly modernized format), it's important that you also assure your SD-MobileLink program is updated to at least Ver. 2.0.25 (which right now is the current release). This version is equipped to pull outgoing mail items (as directed to your techs) from the new structure. If you were to send SD-Mails from the new structure to your techs (and if still using an older copy of SD-MobileLink), that older copy of MobileLink would not be equipped to forward those SD-Mails onward to your techs.
New Search Function in Inventory Control:
In the InventoryControl form there is a "View Raw Data" option (F10→I→V). When this option was made, it was not believed it would have much operational use (the biggest reason we made it was so you can simply see what the direct underlying data looks like). However, it turns out some people are using it with some frequency, particularly when wanting to manually edit spec tags. Given that, we have added a search function there. To invoke it, use the conventional Windows command for the purpose (Ctrl-F, the "F" is for Find).
New Accommodations for Spec Tags in Inventory Control:
When we first made spec tags, we thought they would be sort of a light-weight, minimal-consequences feature. Honestly, it's how we intended them. Turns out folks have wanted to make very robust and extended use of them, and it's pushed us to continue to upgrade and increase associated capabilities. This is another instance. Actually, it's two others.
First, if you are looking to see what quantity you possess of a particular stocking part (and in what locations, F10→I→F), it may be important to know that one or more of the indicated items are presently tagged for other jobs. The system will now let you know.
Second, when you are wanting to order restock, it could be important to know that one or more of the items that presently satisfy your minimums are tagged, and so you may need to order restock where otherwise you would not. Again, the system will now let you know.
Alternate Part Numbers Now Have Operational Significance:
For a very long time, our MasterPartsPlan (Ctrl-F11) has featured a SupplementalInfo window. Click in the vertical green band just to the right of any line-item, and its SupplementalInfo window will display. Among other things, in this window, you can list up to five alternate part numbers, for the primary listed item (these are in addition to the two alternates that can be placed directly within the line-item itself). The sad thing, all this time, has been these five alternates have simply been present there for you to see and review, but have not otherwise entered operationally into actual use.
This is now changed (and, actually, this change was shortly after the last prior entry in this blog, the one just below).
Now, any alternates that you list are included in all the applicable as-you-type drop-downs. So, say your main listing for an item is ABCD, but you have a SupplementalInfo alternate for it listed as EFGH. You can type either of the targets, see it in the dropdown, and select either for identification of the part of interest. BTW, this same enhancement extended into SD-Mobile as well.
You May Now Make "Fake" Technicians:
Since forever, ServiceDesk has allowed you to use "fake" serial numbers in a UnitInfoSheet (though, of course, we use the somewhat more uppity expression of "pseudo-number"). Since October of last year, ServiceDesk has also allowed you to make "fake" appointments (see entry in this blog accompanying Rel. 4.7.2) -- though again, for formality, we use the expression "pseudo." Now we introduce a third "fake" actor.
The genesis for this one came, actually, from the same shop that led us toward the last one (Guinco in Fort Worth, TX). Jeff Guinn called to explain how they are now finding it almost essential to specialize each of their techs within particular areas of competence (laundry, refrigeration, cooking appliances, etc.). The problem is they want to keep most of their appointments unassigned until the day prior, but it's important from within the DispatchMap to see which jobs (and how many) fit into each competence category. For this reason, Jeff and his team created some artificial technicians. In the Settings form (Ctrl-F1), they created a tech called "Laundry," one called "Refrigeration," and so on. In result, they obtained list areas in the DispatchMap where each appointment could be temporarily assigned (for the kind of competence it required), until the day prior, at which point it would then be assigned to an actual/true tech. In other words, they used the device of a "fake" technician to create a semi-unassigned category: not assigned to any particular/actual tech, but nevertheless assigned to the competence category.
Jeff reported that, though generally the scheme was working well, it had some shortcomings. One of them was that ServiceDesk, not knowing that "Laundry" and "Refrigeration" were not real techs, would within the DispatchMap dutifully draw route-lines between each assigned appointment. This made the DispatchMap look like an awful mess. In many other places as well, treatment of the fake techs, as though real, created issues. What was needed was some mechanism that would allow these fakes to be treated more genuinely like the unassigned category, within the DispatchMap, and not like a real tech otherwise.
So, we have now added a new technician property. If you go into your Settings form (Ctrl-F1) and click on any tech listing, it of course brings up the TechnicianProperties window as applicable to that tech. Here is what it looks like now, with our new addition:
If you actually check the new box, you'll see the system removes most of the other settings options, because they cannot realistically be applicable to other than a real tech:
(Please note that if, when selecting to make a tech fake, you have already picked options that make no sense for a fake tech [such as to indicate 'Using SDM', for example], the system will not undo those settings [even though they become no longer visible]. To fix any such situation, you should uncheck the fake-property box [so as to make such settings again visible], fix the wrong settings, then check again.)
There are a few score of operations where ServiceDesk tallies through your set of techs for a huge range of purposes. We have endeavored to modify everyone of these so as to ignore techs as now designated fake, except for the particular purpose where you may want them treated as though real (specifically, where you are using as a device to make a competence category, for temporarily assigning appointments, within the DispatchMap). It's possible it will be discovered we missed one or more such operations. If you discover this, please let us know.
New "Global" Part Number Search:
ServiceDesk tucks parts information into quite a few places. There are important operational reasons for this, such as the fact special-order parts are best managed via a system specifically tailored to their purpose, while stocking parts are best managed via a system differently tailored to their purpose. Regardless (and as is true with any kind of machinery), to attain a gain in one attribute of performance a price must paid elsewhere. In regard to parts management in ServiceDesk, one such price is the fact, if you happen to be interested in reviewing all of your company's dealings as applicable to a particular part number, you might need to look in a variety of places.
Let's suppose, for example, you are interested in seeing everything your operation has had to do with part number 341241. It's possible this part has been special-ordered one or more times. To find any such events, you'd need to do a search in the current PartsProcess area (F8-->M-->type-the-target-characters-->hit-Enter), and do the same in the archived context (Ctrl-F8-->M-->type-the-target-characters-->-hit-Enter). It's also possible 341241 is a stocking item, and, if so, you might want see both what is your stock-movement history on it, plus inquire as to what you have in stock presently, and where. To separately determine these elements, you'd need to go your InventoryControl form, and there do two different searches (F10-->U-->P-->type-the-target-characters-->hit Enter for history of movements; and F10-->I-->F-->type-the-target-characters-->hit Enter for current stock at each location). It's possible, even, you'd want to examine the anchor listing for this item in your MasterPartsPlan (Ctrl-F10-->S-->type-the-target-characters-->hit Enter).
To be sure, we have long had contextual cross-links between some of these venues, so that with an easy click from one you can instantly see what another has to show in regard to the same part (if in the MasterPartsPlan, for example, a Ctrl-Right/Click will direct-open the InventoryControl form's view of quantities for that item at each location; and, vice versa, if in the InventoryControl form a Ctrl-Click on an item will instantly open its anchor listing from within the MasterPartsPlan). Regardless, there has been no simple, "one-stop-shopping" method via which to instantly find everything ServiceDesk has to tell you about all its dealings with any particular part number.
Recently, a client (Ray from AAA Appliance in Plano, TX -- what is it with these Texas guys?) all but insisted we provide this, and it seemed like a reasonable idea.
The new feature is accessed from within the PartsCrossover form, via a simple button (shortcut access is Shift-F8-->G). Here is what the new button looks like:
You may either use the shortcut above-descried, or click with your mouse. Either way, a dialog box will ask for your search target. You may type as much or as little of the part number of interest as you wish. In response, the system will automatically open all relevant searches for you, and display the results.
Optional/Added Part Numbers Now Have Operational Validity:
This is one we should have done a long time ago. We so much should have done it long ago, it's quite embarrassing it has only been done at this late date.
In the inventory system, each stocking line-item has an attached Supplemental-Info form. In the MasterPartsPlan (Ctrl-F10), you can display this form by clicking in the green band, just to the right of each line-item. In the InventoryControl form (F10), a simple click on most listings will display it. Within the form there is a section for listing up to five alternate part numbers. These are alternates that may potentially be used in addition to the two, in-column alternates that can be created within the face of each line-item (those base-level alternates are identified as IndustryNumber and OtherNumber). Thus, you may store up to eight different part numbers, as connected with a single line-item. But there has long been a difference between the base-level alternates (only two) versus the five Supplemental-Info alternates. The latter have not been included in any of the as-you-type searches, and therefore have had very limited usefulness.
That oversight is corrected with this release.
Now, when your system rebuilds the underlying index that enables as-you-type identification of stocking line-items, it will include in its index build all of the alternate numbers you have listed in Supplemental-Info. So, when you go type any of those in a contextually-applicable context (including your techs in SD-Mobile), you'll see references as needed:
Picking an alternate reference will select the core, underlying line-item, just as you'd otherwise expect. I am sorry we were not quicker with this obviously-logical improvement.
Added User Fields Now Available for Customized CyberOffice Emails, and Two-New Customizations Now Available:
In November of last year we added significantly to the set of CyberOffice-connected emails where you may customize the text to more perfectly fit your own particular preference, taste and circumstances (see entry in this blog accompanying Rel. 4.7.63). Each of the emails involved can use from among a particular set of fields, where actual/particular text replaces a mere placeholder in the customized text (e.g., "We are reminding you about your appointment scheduled for [Appointment]."). In general, we made available to your customized text only the particular and same fields as were used in our canned/default text. It turns out, in some of these emails, some of you wanted to use other fields. This release adds significantly to the list of fields available in each of the potential customizations.
For details, please see pages 18 through 23 in the CyberOffice Handbook.
Additionally, we have added two new items, to the list of auto-sent emails where you may customize the text, as opposed to using our direct canned text. In fact, I believe with these two additions all auto-sent emails are now subject to potential customization.
The first item that is newly subject to potential customization is the Survey-Invitation, as sent my SD-MobileLink. This particular email is something of an oddity in that, while its functionality is indeed part of the CyberOffice suite of services, it's in fact the MobileLink program that does the actual sending. The reason is, mechanically, it simply works out better that way.
The second item is an email that's also sent by the MobileLink program, but it's actual Mobile function. It's sending of the e-ticket to the customer.
Instructions on how to do the work for these newly-customizable items is likewise found in the CyberOffice Handbook, but on page 24. It may seem odd that we've placed instructions there, for how to do customizations for emails as sent by SD-MobileLink. We simply thought it would be easiest for you if all auto-send email customization instructions were in one place.
Incidentally, for these last two customizations to be possible, you must update your copy of SD-MobileLink to at least Ver. 2.0.15 or above.
Twice as Many Zones May be Deployed (Now 60, as Opposed to 30):
Though it's a rare situation, a very few clients have wanted to divide their territories into more than 30 zones (30 is the max quantity of divisions that has prior been accommodated for). With this release, you can now make up to 60 zones.
The change involves more than just restructuring elements within ServiceDesk. Because they are involved in zone/availability management with third parties, each of the DispatchLink utilities (SBDL, SPDL and LGDL) also had to be updated with ability to manage the increased quantity of zones. So did the SD-CyberLink utility, for its uploading of availability information for your own customer's online scheduling. Updates have been posted on all of these, in addition to the update on ServiceDesk itself. It's important, if you choose now to setup with more than 30 zones, that -- in addition to updating ServiceDesk -- you also update any such utility you may be running.
As an incidental byproduct of updating all these utilities, each has also been updated with internal wherewithal to inform the ServiceDesk's new "Command View" of its running state (a feature announced in the last-preceding-update entry).
Other DispatchLink Utility Improvements:
A couple of releases back, we added an option in SB-DispatchLink (SBDL) that changes how holdbacks are calculated. For clarity, holdbacks refer to the practice of withholding portions of your availability from exposure to the third-parties these utilities link to. The general idea is that, typically, you do not want third-party-administrators and/or OEM-warranty clients to hog all your available capacity, and thereby leave you with no room left for your own more profitable COD work. So, the DispatchLink utilities have long had a couple of parameters you can set to "hold-back" a percentage or quantity of slots within each scheduling pocket. This holdback method was somewhat blunt, so earlier this year we added a far more sophisticated method (see entry below dated 1/7/14) that lets you far more finely specify holdbacks -- in particular, as specific to individual zones and days of week.
Anyhow, for either situation the holdbacks have been designed to apply to the quantity of slots you had remaining for a given scheduling pocket (i.e., allocation minus present burden), rather than to the raw allocation. One of our users provided some good arguments for why it would be better (at least for certain situations, such as his) for the holdback specification to apply against raw allocation instead. So, there's now an option in each of the utilities to apply instead on that basis. For example, in SBDL it looks like this:
Other ZoneScheduler Improvements:
While overhauling our within-SD ZoneScheduler interface
(Shift-F5) to accommodate more zones, we made some incidental GUI
improvements. Most notably, if you have ServiceDesk itself
expanded when the ZoneScheduler form is opened, the ZoneScheduler
interface itself will expand to take advantage of the enlarged available
space. This may be particularly useful if you decide to setup with
a very-large quantity of zones such as is now available.
New "Command View" Offered from the About ServiceDesk form:
If your office has more than just one ServiceDesk station, you may find yourself wanting to know (and perhaps monitor) what systems are turned on and running at other stations. This is particularly true if your office is running multiple utilities, such as SD-MobileLink and/or SD-CyberLink, for example, or any of several others. Until now, there has been no way to directly monitor this, except by checking directly at other stations to see what is running there. Now we have a method.
To use the new method, go to your About ServiceDesk form (it's the first option under File Functions in the main menu, or a handy keyboard shortcut is Shift/Ctrl-A). There, you can simply move mousepointer over the textual area that indicates when the Auto-Archive last ran:
In response, there will be an immediate pop-up, looking something like this:
To put it another way, this method is similar to invoking a Windows ToolTip (i.e., float your mousepointer over something), though this is a more elaborate ToolTip than is typically the case.
As you can see, this one provides a ton of potential information regarding what's running within your system, and where, and how currently.
The current release of ServiceDesk is configured so that each instance posts more information (regarding what is turned on and where), than before, so as to make more such information available here (where posts were done in older versions, the information as available to show you will be more limited, as in the case above regarding the WipAlert feature being turned on at the desk of Karie Spaet).
Also, each of the relevant utilities must be updated to do their own postings of information, for showing in this report (in other words, until and unless you are running a utility that has received this updating, it will not do the posting that's needed for this report to see its information). We will be updating each of these utilities, for this purpose, within the next following few days.
New Option to Omit the Offer to Reschedule, within the Online Confirm-Appointment Interface:
This one was driven by some servicers wanting to improve their metrics as measured by certain third-parties, such as Whirlpool. Among other measures of concern are days-between-dispatch-and-first appointment, and days-between-dispatch-and-completion. The direct matter of concern is, when you make it easy for a consumer to reschedule, they tend to do so with more frequency than otherwise.
So, say on Monday you get a third-party dispatch that's scheduled for two-days hence (i.e., Wednesday). If you in fact fulfill that appointment on Wednesday, it will be fairly good for your metrics. But suppose on Tuesday you use the SD/CyberOffice feature to email the consumer a reminder, with request to click on hyperlink to confirm they will be there on Wednesday. Your consumer gets the email, clicks on the hyperlink, and sees this as the interface:
Your consumer sees the offered re-schedule button and thinks: "Ahhh, maybe it would be more convenient to pick another date." So, he or she clicks on the button, and picks a date two weeks out. Now, because of that one incident, your metrics are caused to significantly suffer (I was going to type "shot to hell," but we should not use that kind of language in a professional blog).
So as to make this kind of scenario less likely, we were asked to make an option to eliminate the reschedule button. We figured most people will likely want to maintain the button for COD customers, so we configured the new option, within Settings form, as follows:
As you can see, you are basically allowed to have the Re-Schedule button taken away for all your jobs as associated with High Volume Clients (aka "HVCs," these are the parties for whom you have setup QuickEntryTemplates, and for whom you have created two- or three-letter HVC abbreviations within their templates).
If you wish to use this feature, just go to your Settings form (Ctrl-F1), and invoke the sub-settings window for appointment reminders by clickong on this button:
Then, check the indicated checkbox option (i.e., as illustrated two items above). In result, the confirmations interface as seen by your consumers (specifically, those where the paying party is setup as a High Volume Client, and for all invitations as sent after you've made this change) will look like this:
We hope you like it.
Pre-Screening Jobs: Improved Mode of Review and Check-Off:
It's not the same world it once was -- at least so far as concerns appliance service (apologies are repeated here, for those of you who work in other industries, for the fact our focus predominates on appliance service). It used to be you could stock just a few hundred parts on a truck, and it was sufficient to produce a high rate of first-time completions. Not any more. Because manufacturers now use so many specialized operative parts, the only way to get a good first-time-completion rate is by advance-examining each job -- before the tech goes out -- and seeking on such basis to advance supply him with such parts as the symptoms suggest he may likely need. Most service companies refer to this as "pre-screening." Borrowing from the medical field, a few others refer to the process as "triage."
It was way back in '05 when we were first asked to add programming elements into ServiceDesk to specifically accommodate triage. It should be noted, in this regard, any need for special treatment of actual parts, as involved in triage, relates solely to transfers from inventory (i.e., pulling items from a storeroom shelf, for the tech to take with him), as opposed to special-order parts. For the latter (i.e., where you choose to special-order a part without first having a tech's on-site diagnosis proving need), the standard ordering mechanisms work just as perfectly as otherwise. For pulling items from inventory, on the other hand (and specifically as connected with triage), standard mechanisms do not work so well. There are a few reasons:
Unlike special-order items, inventory items are not normally (i.e., absent some special system otherwise) tagged to a job. Thus, absent some new and added mechanism, there was no way to know on the day of an appointment that the tech needed to be taking a pre-screened-for-the-job inventory item with him.
Though the inventory system could nevertheless be used to simply transfer a pre-screened item from office to the tech (i.e., so he'd then have it with him when going), there was formerly no system to flag, if the tech ended up not using the part, that it now needed to be retrieved back from him.
Even the above assumes you can reliably predict which tech will be fulfilling an appointment. This is often not true, and even if you have fairly definite plans, they can change (say the intended tech gets sick). This makes any advance transfer, of a pre-screened-I-think-it-might-be needed part, problematic regardless.
Another factor is you might end up needing a pre-transferred part elsewhere (e.g., for an across-the-counter sale). It would make better sense to have it still in the office and available for such immediate use, as opposed to sitting in a tech's inventory waiting the day of an appointment on which it might be used.
Based on these factors, we created what we affectionately call "Speculative Parts Tagging" (a sub-part of which has sometimes been referred to as the "Anticipatory Parts Transfer"). The system was primitive at first, but has been augmented many times since, so that today it is reasonably robust.
At least, in and of itself, it has been pretty good. Where it has lacked is regarding the larger environment in which it lives. Specifically, we have not had any very good mechanism to facilitate having a particular person in the office know which jobs are due for pre-screening (i.e., just providing a simple on-screen venue in which to easily iterate through those particular jobs), and to readily distinguish those from ones that have been pre-screened. It's a need that exists, indeed, whether your pre-screening results in spec-tagging from inventory, or special-ordering items that were not prior in inventory. Either way, a good context of selective review makes excellent sense. In its absence, folks have improvised with existing tools, though none have been been perfect for the purpose.
We have had sort of a tool (a poor one, but a tool nonetheless). Introduced in 2010, this mechanism involved a then-new check-off symbol in the DispatchMap (where every appointment always has some particular check-off status). To indicate any particular appointment has been pre-screened, we made it so you can there toggle its check-off status to the CR symbol, as illustrated here:
For at least some, this provision allowed the DispatchMap's roster of jobs to function as a workable pre-screening (let-me-see-the-jobs-that-need-it, and distinguish-from-those-that-do-not) venue. For most users, however, it has not been ideal. As but one of its shortcomings, it's really a job that needs to be pre-screened, as opposed to the appointment for a job. There are many others, but I'll not review them further except to say: I have described this old triage environment for the sake of providing context for introducing what's new. In a nutshell, the tool as just described was formerly the only purpose-provided tool we had for this need. Now, we have created something far better.
As mentioned, it is much more a job that needs pre-screened, rather any particular appointment for a job. Hence, the ServiceDesk JobRecord form (F7) now has a new control. In default mode, you'll see it looks like this:
If you click on it, you'll get a dialog like this:
If you answer "Yes," the new control will change to look something like this (with particulars as apt, of course, to the circumstance):
There will also be a notation, automatically added to the JobRecord's narrative history, similar to this:
Thus, each JobRecord can now readily show on its face whether it's been pre-screened (and, even more, by whom and when). And, it's permanently in the history. This latter is important because, if need should arise, you can also toggle a job back out of pre-screened status (via method, dialog and results similar to as above-described, though opposite in effect):
To clarify, this method is intended to supersede use of the CR-symbol-check-off within the DispatchMap (at least as a mode for providing an optimized venue for conducting the pre-screening process). Even so, we have not removed those symbols from relevance in the DispatchMap. In particular, when you make an appointment for any job, its check-off status will automatically be set equal to whatever is the pre-screened status of the underlying job. Additionally, when you change the pre-screened status of a job, the system will reach out, find any pending appointments as belong to that job, and change their check-off statuses to match (assuming they have not advanced to any check-off stage beyond the CR symbol, in which case they'll be left unaltered). The general purpose is so you will continue to have pre-screen check-off visibility within the DispatchMap, though the real venue of operation has moved from there into, more specifically, the JobRecord environment.
So, all this is pretty good, even excellent -- except something more is needed.
What is that something more?
Very simply, you need a convenient and powerful venue from which to review solely those JobRecords that have not yet been pre-screened. You need this, to accommodate the process of doing the pre-screening on those particular jobs. In other words, you need an optimized triage venue.
With one added enhancement, our wonderful JobsPerusal form (Shift-F7) now fits this bill perfectly.
Formerly, the bottom-right corner of the JobsPerusal form had these exclusion options:
Now, there is a new one, as shown here:
So, there it is. All your pre-screen person must do is go to the JobsPerusal form (again, Shift-F7), pick any other inclusion-or-exclusion filters in which he or she is interested, then "check" this new filter option. He will then be shown solely those jobs on which the pre-screen process is still pending (assuming, of course, he has prior checked-off all that have prior been pre-screened). As he then goes through each such item in what is effectively a "needing-pre-screen" queue, and does the needed work, he'll check-off each item, and thereby gradually reduce the queue to none (and it will remain as none, of course, until others in the office add new jobs into it).
Honestly, we think it's pretty ideal. We think you're going to love it.
New Method for Managing Expectation for Above-1 JobCount Values on Upcoming Appointments:
A job is in waiting status (perhaps waiting for parts to arrive, for the customer to return from a vacation, or whatever else is the case). You know that eventually you'll be making an appointment for the tech to fulfill, and you know this new appointment must have some particular JobCount value greater than 1
How do you assure that, when it's time to make the appointment, you remember to insert this greater-than-1 JobCount?
Or, imagine another scenario.
You had an appointment with a greater-than-1 JobCount, and for whatever reason it was canceled. You know it's going to be re-scheduled. How do you assure that the re-scheduled appointment gets the correct, above-1 JobCount value?
Until this release, ServiceDesk has not had a truly magnificent system to assist you with this. Now it does.
At its most basic, this new system depends on a specialized kind of AttentionNote (most folks call these "sticky notes;" they are the little-yellow electronic notes that can be added into a JobRecord). For a long time, there's been another particular kind of AttentionNote, called a "JobLink." The purpose of this kind is to associate jobs one to another (see entry here accompanying Rel. 4.1.123). Now we introduce a second kind of particular such note. What makes both kinds "particular" is that, based on very specific internal text, ServiceDesk knows to react in special ways, based on their presence.
Naturally, there was already a method by which to create the JobLink specie of AttentionNote. To accommodate this new particular specie, we have simply expanded on that method.
More specifically, in an F7 JobRecord form there has long been a button on which you may click to create a standard (you-type-in-what-you-want) kind of AttentionNote. There has also long been a slight variation on this button. Since introduction of the JobLink specialized kind of note, there has been the option to do a right-click instead of a simple left-click on that button (or, if preferring shortcut keys, the alternate command is Ctrl-E as opposed to the standard, left-click-mimicking Alt-E). There is also a reminder ToolTip for this variation, as you'll see by floating your mousepointer over the button. Prior to this release, such mouse-pointer floating would produce this:
Now, it instead produces this:
It's not a lot different, but as you can see the ToolTip now suggests there will now be more options than just one, when you choose this alternate method for invoking the button click. Indeed, the right-click option would formerly have taken you directly to the dialog to produce reciprocal JobLinks. Now, it will instead produce this:
As you can see, it now produces a choice between the old (and formerly only-offered) option, versus instead choosing the particular new option, that we are now talking about.
When you choose that new option, you'll get a dialog like this:
And when you enter your desired-for-next-appointment JobCount value, ServiceDesk will insert an AttentionNote to the JobRecord similar to this (this is, specifically, the result you'd see if indicating the next appointment should have a JobCount value equal to 3):
Now you may wonder, with that note there, does it simply provide you with a reminder -- that you must personally pay attention to when making the next appointment?
No, it's much more helpful than that.
When you go to create an appointment for any job, ServiceDesk will now on its own accord look to see if any such AttentionNote (i.e., with text precisely as per above, though the actual number can vary) exists. If so, it says to itself: "Aha, this appointment should have a JobCount value of X." Upon so concluding, ServiceDesk will auto-insert that value for you, into the new appointment (of course, you remain free to edit differently if desired). And, upon creation of that new appointment, it also automatically deletes the AttentionNote for you (it's done it's job, after all, and should no longer be needed).
That's the basic functionality -- though behind-the-scenes it gets a little more complex for some situations.
To illustrate why, suppose your customer cancels an appointment that has an other-than-1 JobCount value (something came up, and there's intent to reschedule in the future). If this occurs, ServiceDesk will behind-the-scenes automatically create a new, specialized AttentionNote to assure the next appointment appropriately gets the same other-than-1 JobCount value as the one being canceled. At least, it will do this for a normal cancelation. However, suppose you indicate that the appointment you are deleting was simply an erroneous entry. In that case, the system figures it better make sure of what's needed, and presents you with a dialog like this:
Another somewhat tricky situation arises when you decide to change an existing appointment, and if one of those specialized JobCount AttentionNotes is present, and with a value that does not correspond with what's in your being-edited appointment. How should the system respond to this situation. Since it's unclear, it will present you with another dialog, as follows:
If you are wondering, BTW, yes, this new functionality also works when your customers self-schedule online (via SD-CyberOffice) for any return visit. The SD-CyberLink utility will look for these same specialized AttentionNotes, and upon seeing any will assign the needed JobCount value to any relevant appointment as online-created (though you must be updated to at least the now-current release of SD-CyberLink to make this happen).
If you are further wondering, yes, this new power also translates into interaction via SD-Mobile. More specifically, a particular section in the tech's Mobile PVR page has been changed . . .
From This . . . | To This (new/added function highlighted): |
|
|
As you can see, there is now explicit provision for the tech to indicate the JobCount value as needed for his next visit.
By way of distinction, this new facility applies, in particular, to the situation where your tech is leaving it up to the office to schedule his anticipated return -- as opposed to using other facilities that exist within Mobile for doing his own direct-booking. This latter situation has long been covered, so far as JobCounts are concerned, for the facility that allows direct-booking lets the tech directly-specify a desired JobCount for the appointment he is himself creating -- and that count goes right in, directly, to the actual appointment that results. It's only where he is leaving it up to the office, to re-book (and for an appointment that will not yet exist), that a concern has existed. And that is, of course, where this new facility (as above shown) comes into play.
Where the tech uses this new facility to indicate any JobCount value other than 1, SD-MobileLink will automatically create that new specie of AttentionNote, within the applicable JobRecord, as it downloads and processes the tech's PVR (concurrent releases of both SD-Mobile and SD-MobileLink, or higher, are required to enable this added functionality).
All in all, we think you'll love this new feature. We hope you'll take advantage of it.
One more thing (and if you're wondering), yes, if it's to be operative, the text as inserted to the AttentionNote must be in exactly the form ServiceDesk creates it, when you use this option. If you were to manually type exactly the same text, it would indeed work just the same. However, if your text was even one character different, it would not work the same.
Improved Prompting to Read About New Features:
We have two different online WorkDiaries: one for ServiceDesk and another for the SD-Mobile system (we likely should have added WorkDiaries to chronicle and explain new features in other products, but, to date, there are only those two).
We very much want you to read the new entries in these, as you update and have available the new features that are explained. It's been somewhat tough to get most people to do this. Initially, we added a little dialog in the update sequences that offered to open the applicable diary for you (i.e., the one for ServiceDesk if that's what you're updating, or the one for Mobile if you're updating either SD-Mobile or SD-MobileLink). We found most people did not read still, so we changed the dialogs. They no longer offered a choice, and simply opened the diary pages for you (except with ServiceDesk you could choose to do it before or after you downloaded the update). This also proved to be not very effective. The applicable diary would open, and most people simply ignored it. For many, it was more a nuisance than a help.
So, enter Phase 3.
Now (and we really hope this is what makes a difference), you will not be invited to open and read the online Diary unless, in fact, it contains a new entry that's pertinent to the version you have updated to. And, you will no longer be denied a choice. However, the system will, once in each run session, continue to invite you to read an applicable diary entry, until you consent to at least let it open for you. Once you do this, it will not pester you again until and unless there is, in fact, a new entry posted that you have not yet opened to.
We hope this proves to be better.
Of course, if you were one of those that never responded by reading, you'd not likely be seeing this posting either. c'est la vie!
Added Visibility for WP-Measured Average-Days-to-Completion:
For those of you doing Whirlpool work, we understand there's a recent renewed emphasis on certain metrics -- one of them being the average of days between dispatch and job completion. We have long given you a number of insights into this.
For example, F11-->C-->Q will produce a report (it's called the "Quality of Service" report) that, for each high-volume-client (including WP-Warranty and/or WP-Contract service, as applicable) will indicate several figures, including quantity of days from first visit to completion (not quite the same as from dispatch from completion, but useful nonetheless).
Similarly, F11-->C--P will produce a report (called "Performance Metrics") that's specifically tailored to, as near as possible, match several of Whirlpool's own focused metrics, including separation between average days to completion on jobs with-parts (and this is indeed from dispatch to completion), versus average on jobs without-parts. But, it will only show such indications based on specification of the underlying client, and not on basis of whether it's a job (regardless of client, and regardless of whether it was COD or not) that was dispatched to you by Whirlpool.
Still another relevant report can be navigated to via F11-->T-->M (its called the "Percent of Completions" report). It's also an excellent resource. Among other meaty morsels of info, it indicates average number of days from first visit to completion. Again this is different from average of days from dispatch to completion, but (and, more seriously, so far as the desired metric is concerned) the breakdown has divisions via techs, rather than via dispatching entity.
So, though all the above provide a rich resource set, none was quite the
perfect fit some of you have desired. Based on this, we have now
augmented the "Checking Data" export as provided appurtenant to the last
above-described report (look for the "Export Check Data" button that
appears after the report displays). That export formerly had just
five data fields. It now has 13, including an indication of
whether each applicable job was dispatched to you by Whirlpool
(and regardless of whether it was COD or otherwise). If you run
the report then produce the export, we think you'll find the added
fields provide a great deal of raw data -- which you are free to
manipulate (this is rather easy in Excel) for whatever analytical
purposes as may suit you.
In-Process, Explicit Warning Re Applicable SSA:
The Special Situations Advisory (SSA) is designed to let you make a unique record, as applicable to a particular customer or address, involving some special situation as applicable to that customer or address (e.g., he's deadbeat, do not perform service for this person). Whenever you are in a Callsheet and type in a name, address, telephone number or email that matches an applicable SSA item, you'll see references to that item (along with other references in the CstmrDbase showing). These will be distinguished by the fact there are # signs in the line listing.
Until now, it's been up to the user to visually notice such a listing, and volitionally click on it, to then review and take into account whatever is disclosed in the item. The problem is, a user might fail to notice, or may not bother to volitionally review. There was desire for the software to more directly "force" the user to notice. That's what this improvement is about.
When a user clicks to "Job/Sale" from a Callsheet, the system now checks for either a name or address match in the list of SSA items. If there is a match, the user gets a message similar to this:
After being shown the SSA as applicable (and then closing it), they'll
then get this:
Beefed-Up Multi-Tech PartsPick Export:
A while back we added an option to export from the PartsPick form (Shift-Ctrl/F8) a summary of items needing moved for a particular tech (see entry below for Rel. 4.7.47; we added a button in the form's bottom-right corner). Thereafter another user wanted the ability to do similarly, but for all techs, and via a single click for all. For this (and though the addition was not then here announced), we added a button to the form's bottom-left corner):
This new button was thus significantly powerful, but still left some movements to be managed separately. Specifically, its output accounted only the for the same items as directly managed via the PartsPick form, which by nature deals with moving special-order parts and spec-tagged inventory, but does not account for simple and standard inventory restock.
That's what is addressed in this release.
Output from this button will now include not just what's shown to be moved on the face of the PartsPick form. It will also include what needs to be moved to the tech, by way of simple inventory restock. More specifically, it will show what needs to be moved based on the Items-Recently-Used method.
Additionally, when simple inventory restock is used from this venue, it
will do one better than when using the same method via the
InventoryControl form (F10). In that form, there is at
present no built-in mechanism by which the system remembers for you what
was the last time you ran the process (and which, therefore, should be
the "begin-date" for movements that trigger the next-new process).
Here in this context, the system explicitly remembers the last date and
time, and offers it as default for the current process.
Augmented Intelligence on Exposing Availability:
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 to my.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).
New Functionality Option in SB-DispatchLink Ver. 4.5.53):
This new option relates to Flowing-Pipes, those instruments that allow unused capacity in one zone to be accessible for use in another (for details see the FlowingPipes-Handbook). Potentially, these pipes can be confusing. They allow excess burden in a "flow-from" zone to effectively move into the unused capacity of a "flow-to" zone. What is potentially confusing is that, as burden flows in one direction, capacity consequentially travels in the opposite. The thing you must remember is that any such pipe in itself points in the direction of burden flow. If you keep this well in mind (and remember that capacity moves oppositely) you should be in good shape to avoid the kind of confusion that easily results otherwise.
Anyhow (and in regard to our new feature option), it turns some of our users had found it useful to put all capacity into one of more flow-to zones, and zero capacity in a particular flow-from zone. Logically, they expected that the capacity of the flow-to zones would effectively transfer back into the flow-from zone. This indeed worked just fine so long as the flow-from zone was setup with a capacity of at least 1. If setup with 0, however, it did not work. It turns out the reason for this is we'd coded in some logic governing the potential flows. It essentially said: "If the user has specified zero capacity for this zone, that indicates a definite no, and we should not allow any effective flow of capacity back into it. But, for some users pursing a particular strategy, that's not the logic they wanted.
Hence, this new option is now added:
As you can see, the descriptive text is tiny, so as to fit within the space available. Unabbreviated, it reads:
"0-allocated zones show available if flow-tos have capacity"
If you leave the option unchecked, the system will behave the same as it has historically. If you check it, it will allow any unused capacity from a flow-to zone to effectively fill-in to flow-from zone, even if it's otherwise allocated as having zero capacity.
Generalized Overhaul and Improvement in ZoneScheduler Form:
Often folks are anxious to verify that SB-DispatchLink (and similar utilities, such SP-DispatchLink, LG-DispatchLink, and so on) are uploading correct dispatch-availability info to the third-parties involved. Generally, this can be done quite readily by online review via the third-party's provided interface, to see what availability values have resulted there, then comparing to what's shown within SD's ZoneScheduler form (Shift-F5). With but minor exception, this has worked quite well.
However, there have long been certain machinations, with availability, which the DispatchLink utilities perform (along with SD-CyberOffice, for the purpose of exposing scheduling availability to your own direct customers), which SD's internal ZoneScheduler did not.
For example, the utilities have each long been programmed to automatically do a burden flow between time-segments within a given zone-and-date-pocket. To illustrate, suppose for a given zone-and-date pocket you've allocated 5 slots for morning, 5 for afternoon, and 10 for all-day. Suppose you've actually booked 9 for morning, 8 for afternoon, and 4 for all-day. Technically, you are now overbooked for total capacity (9+8+4=21, which exceeds the summed capacity of 20 as achieved by adding capacities of 5+5+10=20). If a utility was to consider only the afternoon segment, it would conclude you still have 6 all-day slots available, and would then upload that. Obviously, it would not be a good result for you. To prevent that, the utilities are coded to flow excess burden from one time-segment (within any given zone-and-date pocket) into any unused capacity of another.
Somewhat similarly (albeit with a somewhat opposite result), imagine the same capacity setup as above described, but where you've ended up with burdens of 13 all-day appointments, against 2 for morning and 1 for afternoon. In that circumstance, you still have overall capacity of 4 (20-minus(13+2+1)). If no behind-the-scenes adjustment was made, this capacity would be offered exclusively in the morning and afternoon categories (since you're already overbooked on your all-day allocation). But that's not good. You'd rather have folks choose all-day, if they are willing. Given this preference, the system is coded to see where (in such scenario) you have availability across the spectrum of time segments overall (even if not for all-day specifically) and, in such a case, artificially notch up all-day availability to 1, hoping that is the category a consumer will select.
Anyhow, these kinds of machinations were not being managed within SD's own Shift-5 ZoneScheduler form, and it sometimes resulted in confusion when folks sought to reconcile what they were seeing there with what they were seeing (and after an applicable utility uploaded) via online review with an applicable third-party. Particularly because we'd just added an option to accommodate further machination on the utility side, we decided we should upgrade SD's ZoneScheduler form so that it might with greater precision show what is expected to be uploaded to third parties.
While we were at it, we made a plethora of other improvements.
The upper-right-hand corner of the form has been changed as follows:
Old | New |
|
|
We have highlighted the changed area to focus on. The general idea is, previously you could check the provided option and see the graphs change to show the result of your own-created zone-to-zone flowing pipes. Now you may check another option to show the result of time-segment-to-time-segment flows (as above-described), and/or a third option to see where exposed availability will be notched up, in a scheduling pocket, based on availability in associated pockets (again, see above for explanation). You will also find if float your mousepointer over any of these areas, a ToolTip will appear with further explanation. All of it is so you can more particularly judge what is being exposed to others via various online mechanisms.
In regard to such better-seeing, we have also added a new row of numbers in the display, as here shown:
As you can see, this row does the math to indicate remaining availability in each applicable pocket. More particular, if you enable the options to allow the same internal machinations as the DispatchLink utilities perform, this row of numbers should show the very same values as are uploaded by those utilities (i.e., no more confusion).
And there's more.
If you've setup one or more zone-to-zone flowing pipes, do you ever struggle to remember (as you look at this ZoneScheduler interface) which pipes you've setup, running from which zone to which zone, and in what direction? We figured there should be a graphic to assist you, in this regard. (In fact, we'd planned to create it when this form was first envisioned and created back in 2002, but we never got around to creating it until now.)
Now (and finally), the pipes become graphically real.
I just now took a moment, and setup pipes from zone 1 to 2, from 5 to 3 and from 5 to 7. Then, I re-displayed my ZoneScheduler form. Look at what it now displays:
See those new pipe graphics? Aren't they cool!
BTW, the overburden in Zone 1 (as seen immediately above) shows as such because I did not have the option checked to show the result of flowing-pipes. Look how it changes when I check that option:
To be clear, that particular option-to-show-flow has long existed. However, with benefit of the pipe-graphic, it is now much more contextually obvious what is occurring, plus you have immediate, visual verification if you have setup your FlowingPipes.txt file as per end-result wanted.
One other matter is, where applicable, there will now be an indication of whatever job-counts you have assigned to Zone-0 ShopJobs (for more details on the underlying method, see entry regarding Rel. 4.5.68).
Aside from these very functional improvements, the interface has been improved aesthetically. The colors are now much more refined. The form more properly fills its space. There is more vertical space above the "Max Load" line in which an overfilled graph can fully display, before intruding beyond available space. Overall, we think you'll find it to be a much more enjoyable interface to use.
Fix for Duplicated Past Appointments:
In Ver. 4.7.67 I'd made an improvement to guard against a just-discovered vulnerability that could, potentially, result in an occasional loss of an appointment in an office that has multiple users simultaneously working in appointments (such small, behind-the-scenes improvements as that one are not generally announced here; indeed, for every more noteworthy improvement as here announced there are twenty or more that receive no official notice).
Anyway, it turned out there was a flaw in how that improvement was made, and it resulted in appointments for past days (as viewed when you PageUp in the DispatchMap) duplicating. In fact, after each night's archive they'd duplicate again -- so, for a date, say, five days ago, you'd end up showing five instances of each appointment.
This release includes a procedure that will fix those duplications. To run the procedure, open your DispatchMap, and on your keyboard hit Shift-Ctrl-Alt/R (the "R" is for "R"emove duplicates). Just follow the prompts, and the procedure will fix your data.
Generalized Print/Export from F8 PartsProcess Form:
The main concept for working within the F8 form is to do work on-screen. Given this, the primary print or file-output options we've had, there, have been as intended for provision to others (e.g., when ordering parts and needing to provide order info to the vendor). There has also been provision to print labels for parts. And, if wanted, it has forever been true you can print what's presently shown on the screen by using SD's universal "Print-what's-shown" command, which is Ctrl-P. However, there has been no provision for doing a complete output (whether to printer or a file) of all items that fit within the presently-selected display category. That is the option now added. It is accessed via Alt-P, and shows as an option in the contextual CheatSheet:
Added Option in the New "Warn-If-Expected-Part-Arrival-Is-Too-Late-For-Appointment" Feature:
Sometimes I receive a nasty reward for having created an awesome new feature. It is someone responding with: "Oh yeah, we love that, but now you must make an option for us to do it differently."
It happened with the new feature described just two items below. In creating that feature, we assumed you need to be receiving a part at least the day prior to appointment date. Turns out this is not true for some operations. In particular, there are some that have their parts vendor managing parts for them (indeed, filing each tech's tote before a messenger delivers to the tech's residence, on a daily basis). The ETA for any part that's put into the F8 screen is the date they expect the vendor to be populating the tech's tote with that part. So, for this situation, it's perfectly fine if the date-of-arrival on the part is the same as the appointment date.
Given the above, we now have a new Settings option in the F8-form's Cheat-Sheet (right-click in any non-operative space of the form to get its Cheat-Sheet), as follows:
picking this Cheat-Sheet option | produces this settings dialog |
|
|
The result of this option setting is, we think, self-explanatory. However, if not clear, it's this. With the second setting (which is default) you'll be warned if an appointment is the same date as ETA on the part, or sooner. With the first setting, you will only be warned if appointment is sooner than the part's ETA.
For Serialized-Inventory and POS Operation, Improved Auto-Fill Link-to-SalesJournal Entry:
If you use SD-Dealer for managing serialized inventory (and SD's POS system to conduct sales of such inventory), you may have lamented the fact that, when linking from there to make a sales journal entry, the system did not separate your serialized-inventory sales into the "Merchandise" category of sales. Instead, it would place the value into the "Parts" category, along with any other line items from the ticket. That is now corrected (turns out it had formerly been coded to appropriately separate out merchandise, but without us realizing it that element of functionality was broken when we upgraded another matter, quite a long while back).
Improved Treatment of S.Call Categorization in Mobile FinishedForm, Including its Auto-Fill Link-to-SalesJournal Entry:
When we designed the ticket format for use in SD-Mobile, we strived for a layout that would be useable across a very broad range of charge-structure preferences. This was needed because, for the Mobile context, it is far less practical to provide a structure that allows for infinite user customization of the ticket, such as we do within ServiceDesk itself. One element, in seeking to allow such breadth of use, is the ticket was not designed with inclusion of a box labeled "Service Call." Instead, we made a box labeled "Labor" and a box labeled "Other." We figured this would allow a reasonable fit for both those companies that refrain from charging a separate "Service-Call"-labeled fee, and for those that do (where it can simply be placed in the "Other" field.
By and by, however, we had requests from folks who wondered if we could program an option where, with a simple settings change, that "Other" field could have it's label changed to say "S. Call" instead. We assented and created the option. It's in the MobileLink program, as shown here:
But, we only programmed to make the option effective within SD-Mobile itself. Nothing was changed within ServiceDesk. In consequence, SD's FinishedForm-context representation of the Mobile ticket continued to show a "Labor" field and an "Other" field, even if you checked the option above shown.
That is changed in this release (i.e., now SD's FinishedForm-context representation of the Mobile ticket will comply with the option you set above). There is another element of change that is perhaps even more important.
When you link from the FinishedForm context to an auto-filled sales journal entry, there must be a translation from which boxes are filed-in on the particular FinishedForm you're linking from, to which fields are populated in the sales journal entry. For going from the Mobile ticket, we've had it programmed so that both "Labor" and "Other" are summed together -- into the Labor category of the sales journal entry line. The reason is because we did not know whether "Other" was used as a service call, or for something else.
However, now that we are bringing into the Mobile/FinishedForm context information about whether that "Other" field is being used, explicitly, as ServiceCall field, we can so handle it. Specifically, if you've picked that option, the system will now translate that box into the sales journal entry's ServiceCall field, just as you'd expect.
Automatic Warning on Whirlpool Core Returns:
In cooperation with Whirlpool, we are now keeping your system up-to-date with a current list of all the parts that involve a core charge. Interactions within ServiceDesk and SD-Mobile will automatically warn when your work involves such a part. The only thing you must to do activate this is consent when asked for permission to install the list (this will occur for appliance servicers only; if you are in another field of service, the prompt will not occur).
For Whirlpool warranty servicers, there is another
feature that works in conjunction with the above. If you are using
a part that Whirlpool would like to receive back as part of its Quality
Assurance program, you'll be prompted accordingly.
Better Management of Processes as Connected with Ordering Pre-Screened Parts, Including a New CyberOffice Transaction Scenario:
More and more companies are pre-screening their jobs to assure a likelihood the tech will have all needed parts with him on the first trip. In many instances this means ordering parts before ever going out. In some instances the appointment has already been made, and you may find -- upon going to order a pre-screened part -- its arrival is not expected until after the appointment date. To cope with this dynamic means doing several things:
As you order each such part, you must look to see if there is an appointment already pending, and, if so, whether the expected arrival on the part squares well with that appointment date.
If the anticipated arrival on the part is not sufficiently soon for the appointment, you must call the customer, explain the situation, and ask to cancel the present appointment.
You must then actually do the appointment cancellation within ServiceDesk.
You must reschedule for a new appointment date (either at the time, or later when the part arrives).
Another factor arises from the fact that ServiceBench is now often including pre-screen part suggestions in its dispatches. The SBDL program places these into a Callsheet's ExtraNotes (which are of course transferred to the resulting JobRecord), meaning (to take good advantage):
You must make a special effort to be on the lookout for these notes, and, upon finding them, you must make significant effort to process accordingly.
We have done several things to aid your work, in meeting these imperatives:
We have changed the F8 form's right-click on job
reference action. Formerly, this would quick-link to the
underlying Parts-Request record. It now instead direct-links
to parent JobRecord.
This is to make it much more
rapid and intuitive to see all the details as offered by the
underlying Job.
If there is a pending appointment for any job that
underlies an F8 PartsProcess item, a ToolTip will appear for that
item as you float your mousepointer over either it's left-most
reference area, or over the DateExpected area. The ToolTip's
color will be green if there is no apparent conflict between
the ExpectedDate and appointment date, or red if there is a conflict:
This is to make it so you don't even have to check the
underlying JobRecord, so as to know about pending appointments --
and so you have a more obvious visual reminder if in fact there's an
issue.
When you insert an expected date in an F8 item's
ExpectedDate box, the system will behind-the-scenes check to
see if there is a conflicting appointment. If it finds a
conflict, it will present you with the following
dialog box:
At least the above is what you'll see if the underlying JobRecord
has no email address for the customer. If it has one, you'll see this instead:
Either way, so long as you are appropriately populating that
ExpectedDate box, you don't have to be deliberately watching.
The system will volitionally inform you of a conflict between
expected part arrival and appointment, regardless.
In the latter case above (i.e., where the JobRecord includes an email address for the customer), you'll notice the first option offers to cancel the appointment for you, plus email the customer with notice of the cancellation, and to include within the email a hyperlink on which the customer is asked to click, for the purpose of scheduling a new appointment (this one, of course, needing to be after the expected arrival date of the part). To do all of the above is as easy as picking that selection. You need do no separate work to achieve the actual cancellation within ServiceDesk (it's taken care of for you, and appropriately documented within the JobRecord's narrative history, too). You need do no separate work to inform the customer. Very likely, you need do no separate work even to get the job re-scheduled, for the customer will likely do it via the email-included hyperlink.
The feature as just described involves our new CyberOffice scenario -- specifically, an invitation for the customer to re-schedule a new appointment, via online interface, when the existing one is cancelled. We're labeling this one Scenario 12. It's pretty simple. When the customer clicks on the email-provided hyperlink, it takes him or her to the scheduling machinery as embedded within your website as part of the CyberOffice system (for this transaction it is particularly configured to refrain from offering any dates that precede the day after you expect to have the part). When the new appointment is made, it plugs automatically back into ServiceDesk, just as do other appointments.
As you can see, the second option in the above dialog offers to do all that was just discussed, but does not include a hyperlink to accommodate immediate re-scheduling by the customer. If you are not yet using CyberOffice, you can fully use this option regardless. Or, in some instances, you may prefer to use it if you simply do not want to re-schedule until after the part arrives.
Regarding pre-screen information that comes from
ServiceBench in an SBDL-inserted dispatch, ServiceDesk will now look
for such items when you do the Job/Sale transition from Callsheet to
JobRecord. If it sees such an item, it will present you with
this dialog:
With your consent in this dialog, ServiceDesk then opens the
underlying ExtraNotes. As you can see here, when you float you
mousepointer over the portion that describes the "PRE-ID" item, a
ToolTip informs you of a wonderful new shortcut:
Just as the yellow ToolTip invites, you may do a simple Ctrl-Click
on the "PRE-ID" text. In response, the system will open a
PartsRequest-creation window for you, where you can then instantly
initiate the process. We feel this should make it so you no
longer need to engage in the deliberate effort to go looking for
these "PRE-ID" notes, and it facilitates more easily going from the
PRE-ID'd item to the actual order creation.
New Text-Customizations Available for CyberOffice Emails as Sent by
ServiceDesk:
The CyberOffice system incorporates a variety of emails that are generated by either ServiceDesk or SD-Cyberlink to automate (or in some instances semi-automate) communication with your customers. In each instance, we have formulated text for these emails that we judge as suitable for the purpose. Occasionally, people want their text to be different, so we have long provided the ability to setup for use of your own custom text in substitution for our "pre-canned" variety. But, this customization ability has extended only to some emails, not all. This release adds several to the list of emails that may be customized.
Emails that have long been customizable include: (1) acknowledgment of an initial order-request as sent by SD-CyberLink; (2) acknowledgement of confirmations, as sent by SD-CyberLink; (3) request to confirm appointment with provided hyperlink (so the customer can confirm online), as sent by ServiceDesk; and (4) request to confirm appointment by email reply or return call, as sent by ServiceDesk.
With this release we add to our "customizable" list the following: (5) emails as sent by ServiceDesk to request initial scheduling on a job (typically involved when service was ordered by a third-party-payer) and with provided hyperlink (so the consumer can do such scheduling online); (6) email as sent by ServiceDesk, as per above, but without provided hyperlink (meaning the consumer must respond by calling the office to schedule); (7) emails as sent by ServiceDesk to inform parts have arrived, with hyperink-provided for the customer to schedule a new appointment; and (8) emails as sent by ServiceDesk to inform parts have arrived, but without a hyperlink (meaning the consumer must respond by calling the office to schedule).
In addition to the above, the two new email scenarios (as discussed in the section above) also have their emails setup as customizable: (9) emails as sent by ServiceDesk to inform of appointment cancellation, with request to reschedule via provided hyperlink; and (10) emails as sent by ServiceDesk to inform of appointment cancellation, with description of intent to re-contact for scheduling after the parts arrive.
The CyberOffice Handbook has been updated to better describe, overall, how to create and implement your own customized text (it has very nice tables now, shows you the default text, etc.). Besides that general improvement, if of course has details as needed for each of the newly customizable contexts:
http://rossware.net/MiniManuals/CyberOfficeHandBook.pdf
To go directly to the topic, please see pages 18 through 23 of the above-referenced document.
"Hlpng"-Type Appointments are Now Appropriately Handled in the CyberOffice
Appointment-Confirmation System:
If you do not know what a "Hlpng"-type appointment is, you should. They are for where you need to send one or more added techs to the same appointment. The primary/lead tech should be assigned the appointment as per normal. Any other tech that you want to send simultaneously should also get an appointment, but with a tiny twist. In place of the customer's name, you should place the precise text "Hlpng" (an obvious abbreviation for the word "Helping"). Typically, you'll follow with a space and then a name or abbreviation-for the tech who's lead on the appointment (as in "Hlpng GR").
These "Hlpng"-type appointments have been a fixture in ServiceDesk since virtually the beginning, and work great. Both ServiceDesk and SD-Mobile know to treat appointments in an appropriately-different fashion, when seeing that "Hlpng" expression in lieu of the customer's name.
Recently, though, a user pointed out one place where we'd not programmed to sensibly account for the difference. He told me when a customer cancels an appointment via the CyberOffice confirmation process, it's only the main appointment that's cancelled. Any potentially-appurtenant "Hlpng" items remain un-cancelled. On investigation, I found it was worse than that. ServiceDesk itself was not screening to avoid extra confirmation requests when "Hlpng"-type appointments were involved. In consequence, the customer could receive a confirmation request on the main appointment, plus further request for any "Hlpng"-type appointment add-ons.
And it wasn't merely an issue on cancellations. Ideally, the consumer should be able to confirm or reschedule on the main appointment only, and have any of those actions transfer to all "Hlpng"-type appurtenant appointments (i.e., it was not a concern solely within cancellations). This likewise was not being done. Clearly, a fix was needed.
This release does all of that. ServiceDesk will now refrain from sending confirmation requests on "Hlpng"-type appointments. More than that, in conjunction with the main appointment it will upload new data to the online CyberOffice data. This new data will indicate the identity of any "Hlpng"-type appointments as associated with the main one. With such data present, the SD-CyberLink utility can now see what appointments are appurtenant, and -- whatever action the user does on the main appointment (whether confirming, cancelling or re-scheduling) -- it can apply the same result to all (this requires an update to SD-CyberLink as well, Ver. 4.5.33 and above will have this improvement).
Improved the DispatchMap's Automated Time-Frame-Insertion Function:
It's possible you don't know about this feature. If it's your office's practice to leave many or most appointments at "all-day" status until working out each tech's route the day before, and if it's further your offices's practice to then convert appointments from all-day to smaller time-frames (so the customer can be informed and not have to plan on potentially waiting at home all day), this feature is for you.
In a nutshell, with a simple action in the DispatchMap (a Ctrl-Click on the tech's name at top of his list of jobs) this feature inserts time-frames for you, using sensible logic according to parameters you specify. It is very much easier and quicker than doing it manually.
Until this release, however, there was a limitation. The feature was designed with expectation it would be working with a list of appointments that all began with all-day status. Thus, if you had some in the list that were already specified for a smaller time-frame, it would balk.
This release addresses that. Now, you may optionally tell the system to simply bypass any appointments that already have a time-frame.
Better Avoidance of Overbooking in SB-DispatchLink:
Several months back we added a feature in SBDL whereby it optionally uploads appointment changes to ServiceBench. This seems to have had an unintended consequence -- in particular, such consequences would potentially arise if yours is an office that engages in the every-afternoon ritual as above-described (i.e., changing tomorrow's appointments from all-day to smaller time-frames as you get the routes worked out). What was evidently happening is as follows:
Say, around 3 or 4:00 in the afternoon, you assign time-frames to a bunch of jobs that were formerly all-day. SBDL dutifully uploads these changes. ServiceBench's machinery then sees the changes, and, accordingly, changes its tally of which availability category each was tallied against. They were tallied against All-Days. Now they are tallied against either Morning or afternoon. Until the next update cycle, this opens up vacancies (formerly filled) in the All-Day category, and suddenly you get a rush of new dispatches as pushed through that momentary opening.
Ver. 4.5.51 of SBDL (available for update now) patches that vulnerability.
A Little Aid on Warranty Claims:
ServiceBench and other warranty processors all require that electronically-submitted claims be configured to fit a particular format, which each uniquely defines for their own exclusive purpose. These formats specify a series of "fields." Each field is essentially a "fill-in" space that expects a particular element of data to be contained within it. Among such fields is one called "WarrantyType."
Historically, this field was used to indicate whether the claim was for "Parts-Only," "Labor-Only," for "Parts and Labor" or it was a claim made under "Special Authorization" or a "Policy Adjust." In other words, this is a field that, in general, refers to circumstances as indicated by the checkboxes at top of the traditional NARDA form:
ServiceDesk has long been programmed to check the appropriate box for you, based on how other boxes within the form are populated (e.g., if you've indicated parts charges but none for labor, and if there is no special autho number provided, it checks "Parts Only" for you). It has further long been programmed to behind-the-scenes translate, when formulating the actual claim string as needed for any processor, to the particular WarrantyType-Code as fits the applicable checkbox selection.
There was a day when the above was reasonably simple. However, in the last few years it's become rather more complicated as the variety of expected WarrantyType-Codes, and variation in selection of Code as expected for circumstance, has proliferated. For example, ServiceBench now requires added codes to report COD jobs in some situations (varying still further depending on if its a referral-program-initiated COD versus otherwise), a different set of codes if the work was for Lowes, and a different set still if you are a Canadian servicer, as opposed to U.S.
As each of these complications has come to light, we have written added IQ into the portion of ServiceDesk that manages the translation, in the effort to assure the needed WarrantyType-Code is appropriately uploaded for each circumstance. Regardless, to make it always right has become rather complex, and potentially difficult to troubleshoot when a claim issue rises.
To assist in such situations, we decided a while back it might be helpful to expose the actual WarrantyType-Code-character the system was translating to (and would therefore upload as part of the claim string) in each instance. Thus, we added a little box in the NARDA's top-right corner, to so expose:
That box was also made editable -- so that, if you know you need a different code than the system is naturally inserting for you, there is opportunity for you to change to that different code.
The small enhancement that's made with this release (yes, the above was indeed much explanation for a small enhancement) is addition of a ToolTip, exposed when you float your mousepointer over the little WarrantyType box:
It tells you precisely what the code-table meaning is, for the code-character that's been inserted for you.
And there's a more substantive improvement. We
discovered a change, that we'd prior added to make certain U.S.-based
claims code as COD when needed, was reacting in an over-broad manner,
and coding some non-COD, parts-only claims as COD (which resulted in
initial rejection and need for manual online correction). That is
corrected in this release.
Fully-Modernized Auto-Dialing:
If you have not prior enjoyed the pleasure of seeing, on your computer screen, the telephone number of a person you wish to dial, and finding you may initiate that dial-out with a simple click, you have little idea how much you've missed.
It's one of those conveniences that, once you become habituated and discover how nice, intuitive plus time-and-effort-saving it is (not to mention how "right" it feels, like the kind of thing that in a modern world you simply should be able to do) -- once you've encountered all this, you'll find it's your feeling that strong men would have to drag you kicking and screaming back to the cave-man world, to ever again take you away from it.
Because this "small convenience" is nevertheless so great, it's one that's been present in ServiceDesk virtually since its inception.
However, this long-standing capacity was programmed, in those early days, to use a technology that was prevalent in those early days. Specifically, it was programmed to use a dial-up modem. You may recall, back in the days before everyone had broadband, if you wanted to connect your computer to the internet, it was done by having it equipped with what was essentially its own "telephone" (aka modem). A standard telephone cord would connect from this item's port to a standard telephone jack. Your computer would literally dial-up an internet provider, and that would be your connection to the internet.
Our long-standing method for auto-dialing (which has continued to work all these years for those implementing it, and, indeed, works still) depends on this modem. Specifically, it makes a call to that modem, telling it to go "off hook" (i.e., same as when you lift the handset on a standard telephone) and dial the number of interest. The idea is, once this dialing has been done, you then pickup your normal handset and continue in normal fashion.
This system has worked, and worked very well, for those implementing it. The problem is that implementation has not been practical for many (or in many cases as useful as it might potentially otherwise have been). There are a number of reasons:
Many offices have phone systems where the jacks as provided to each station are other than standard phone-system jacks (dial-up modems require standard phone-system jacks). In other words, for many offices the jacks talk to some central and proprietary box, and via some protocol other than standard telephone-system language (aka POTS, stands for "plain old telephone system").
Even where a POTS jack is available at each desk (or even a particular desk where the feature is particularly desired), it will in most cases be direct attached to a particular POTS line. If that line happens to be otherwise busy when the user wishes to auto-dial (perhaps in use by someone else in the office), it means that same line is not then available for auto-dialing purposes.
KSU and PBX based phone systems (which otherwise use POTS lines for at least their connection out to the larger world) may not detect when a particular, direct-modem-connected POTS line has gone off-hook. This makes it less obvious when a modem has completed the auto-dial and should be user picked up, or that another user should not simultaneously pickup, etc.
VOIP/SIP based phone systems do not have POTS lines underlying them at all. For these, there are no POTS connections available for a modem to connect into at all (at least absent installation of special-added hardware).
Today's computers are no longer standard-equipped with dial-up modems -- meaning, if you wanted to use this old method for auto-dialing, it's an add-on extra accessory you'd have to acquire and attach to your computer.
The combination of these factors has made it more the exception than the rule, where our users have taken advantage of ServiceDesk's otherwise-wonderful auto-dial capability. We've long wanted to address that, and with this release we finally have.
Our fully-modernized auto-dial feature allows you to use TAPI.
What is TAPI?
It stands for "Telephone Applications Programming Interface." It's a technology (or set of protocols, methods and Windows capabilities) designed to facilitate communication between applications running within Windows and any phone system that is connected to and "talking" to your local network of computers (aka local area network, or LAN). At least, it's designed to facilitate such communication with virtually any such system.
What do I mean when saying "virtually any?" Essentially, your phone system must be TAPI-compliant, meaning its manufacturer designed it with ability to communicate and respond to requests under TAPI standards. Almost all "systems" as manufactured in the last ten to 15 years have in fact been so designed, so if you have a "system," chances are very high it has this capability.
Notice I have also emphasized the word "system." Why? If you have a set of multi-line phones that connect directly to POTS lines (again, ordinary, direct to phone company connections), it is not a "system" in the sense I mean it. At the least, a true "system" puts some kind of proprietary box (often called a KSU or PBX) between you and the phone company's standard set of incoming lines. If you've made the transition to VOIP (likely using SIP as your local protocol), your system does not connect to phone company at all (or at least does not via standard POTS modalities). It may run off a dedicated "black box" or via software in a PC. As long as it is so centralized (i.e., something more than, say, a Magic Jack) it is likewise a "system."
If you have any such a "system" (and if it's connected or can be connected to your LAN) you can almost certainly use our new, modernized auto-dial feature -- and easily, too. In most instances (this will depend on your particular system) it will not even require added hardware. It will certainly require no other connections to the computers in your office (i.e., auto-dialing from each will work through the standard network/Ethernet connection they already have setup).
It is up to you and your telephone system provider to first assure each station (at least each where you want this feature to operate) is setup to properly TAPI-communicate with your phone system. Once that is done, there is but one, very simple element of setup to be done in ServiceDesk. Go to the Settings form (Ctrl-F1) from each applicable station, and in the modem-setting box select "TAPI"
That's it. Really. It's no more complex than that. Once you've done this, ServiceDesk is fully ready to do TAPI-based auto-dials.
It can be done from virtually any SD location where there is a box designated for a telephone number (e.g., Callsheets, JobRecords, Rolodex, etc.). Generally, from such a box, you can either right-click or double-click (for any who do not know, "double-click" always refers to the left mouse button). It can also be done (this is another new element with this release) from any hyperlink-enabled box (e.g., the Description box in a Callsheet or JobRecord, the History box in a JobRecord, etc.) if you double-click on a telephone-number as otherwise free-form-text found within that box.
When you invoke any such auto-dial request, you'll instantly see the auto-dial window:
and, simultaneously, the TAPI request will go forth. I suspect the exact following response may vary somewhat depending on the particular phone systems. When I use the feature in our office's VOIP/SIP system, my extension immediately rings, telling me to pickup the handset or headset (or perhaps the speakerphone, as a third alternative). When I do, the auto-dial window automatically retires, and I find myself then on the line listening to the ring confirmation of the completing call. It's like magic, and is virtually immediate.
I wish I could shout very loudly my urge for you to implement this ASAP. Assuming you have a phone system that is compatible (or that can be made compatible), you'll find it is SO WONDERFUL. It's the way the modern world should work. There that telephone number is, in front of you and on the computer screen, already existing in data form. Why in the heck should you have to read that number with human eyeballs, translate through the wet matter of your brain, think through the sequence of digits then manually punch them onto a pad. That's stupid. The right, sensible and modern way is to effortlessly click on the number, and it just dials. It's how it should be, and how it will be once you assure the underlying setup is in place for your phone system.
In regard to the setup work as needed for your phone system (this is entirely outside ServiceDesk), there are three things you must assure:
Your phone system must be connected to your LAN (it's just a standard network-cord connection, like any other), and must be ready to respond to TAPI requests.
Each station (at least each where you want the feature to be operational) must have an appropriate TAPI-driver installed in its Windows\System32 folder. This is sort of a micro-app that directly manages communication between Windows and your phone system. Much like a printer driver is particular to a printer, this driver is particular to your phone system, and will generally be obtained from your phone system provider.
The Windows "Phone and Modem" setup, at each such station, must be configured to appropriately access the above-described driver.
The above-described elements of setup are not part of your ServiceDesk support. It is between you and your phone system provider to assure they are properly secured. As an easy test to assure you've obtained success, in this regard, we suggest you use the built-in Windows Dialer. It's a phone-dialing utility present in virtually all Windows versions (click on Start, Run and type "Dialer"). If this utility connects to and dials out through your phone system, it means you've setup correctly, and we can virtually guarantee SD's auto-dialer will work with equal perfection.
Please understand if you cannot succeed with this basic Windows test, it is with your phone system provider where you should seek support, and not Rossware. If you can succeed with this basic test, and still have trouble, then of course come to us. So that you know, the first thing we'll do, if you come to us, is test that Dialer. It it works with your phone system, yet you're having an issue using the feature within ServiceDesk, it will definitely be our problem to solve. If it does not work, we'll insist you go back to your phone system provider for the needed assistance.
By the way, if you do not have a phone system (i.e.,
you're using one or more phones, multi-line or otherwise, that connect
directly to standard phone system jacks), we recommend auto-dialing just
as highly (you are simply in the category of folks that could have been
doing it rather easily all along). You can buy modems to add to
your computers at less than $15 a piece (just Google to find them).
Setup is easy. You'll love it.
Rolodex Export:
Ever want to take the ServiceDesk Rolodex (F4) with you? There's a new button for the purpose:
What it does is create a simple document that
summaries the data out of your Rolodex. It's essentially the same
document that is now, by default, made available to your techs using
SD-Mobile. If wanted, you can make an alternate, edited copy of
same for them. For details, see the SDM-WorkDiary.
"Discount" Button Added to POS:
This is an item that's been slow in coming -- in the particular sense that a couple of users have been requesting it for a very long time. To those users, I am sorry it took so long.
Anyhow, it's now here.
In any of the FinishedForm formats (Alt-F4), a tiny new button will be visible in the box that totals the parts boxes. From the POS form itself, for example:
If you wish to add a discount to your ticket, click on the button. It will query as to the desired discount percent (defaults the first time at ".15" for a 15 percent discount, and will default all subsequent times to whatever you picked the prior time). In response, the system will on the bottom parts-listing line insert a discount line item, describing the discount and inserting its amount:
If you edit other parts-listing line items after this insertion, the insertion will remain unaffected. This means, if you want to update the insertion, you'll need to click on the Discount button once again (essentially, it will re-calculate and re-insert the discount, based on whatever is now the otherwise totaled amount of parts-item listings). This item can also be removed (just as can any other parts-item listing) by right-clicking on it.
Improved Insertion of Work-Performed in Finished-Forms:
Recently a user pointed out that, where ServiceDesk reads in a JobRecord's history to assemble a description of the tech's work and insert it into a FinishedForm (particularly and especially into the NARDA, as needed for warranty claims), it was sometimes including text that really was not needed (and in some instances very much not wanted). Especially not wanted were recitations of money collected.
Indeed, we've learned significant resources are in some cases being expended by humans, to manually edit what it's fully possible, instead, to code for machine editing.
This release provides such improved machine editing. Any money-collected recitations, at the least, you should now find are auto-removed for you. If you find there are other elements you would similarly like to see better machine-edited, please let us know.
File-Export Option Added for PartsPick from DispatchMap:
Two releases back (see notes accompanying Rel. 4.7.47), we added a file-export option for PartsPick data as assembled via the PartsPick (Shift-Ctrl/F8) form. This was based on a direct client request.
Turns out, it was not the context where the export was truly wanted. It was wanted, instead, in the much-older context for assembling PartsPick data, which is one of the "Send-To-Tech" options available from within the DispatchMap (F5, to get this option in general, right-click on a tech's name, at the heading of his list of jobs there). Grudgingly, we now offer the option in this context too (both efforts involved a lot of coding work).
More specifically, it's offered when you use the alternate "Send-To-Tech" method -- the one as provided to invoke a "Send-To-Tech" option, but for all techs (i.e., as opposed to just one, whose name you otherwise clicked on). This method is invoked from the DispatchMap via the shortcut-sequence Alt-P-->D-->P. At such point the PrinterSelect dialog comes up, and you simply need to choose for the output to go to file, rather than the printer:
If you're curious, a major difference between the two PartsPick contexts is the older one (from the DispatchMap) was designed to simply to provide a list of what needs moved to the tech. It provides no means to simultaneously tell the system what movements you are (or are not) making. It also does not indicate items that need to be received back from the tech. Overall, the much-newer PartsPick form is far more powerful -- though each may have their particular place, depending on your mode of operation.
Enhancements for Clients on RSS:
RSS is our acronym for Rossware Server Solutions. It's the option where you can pay us to host a server for you, which makes it easy for each of your office personnel to log into ServiceDesk from any computer at any location. It's still a reasonably new offering, and we are still learning to tweak things in its regard. Until now, we have not tweaked elements directly in ServiceDesk. Recently, we realized a need.
First (and as you may know), if you're not actively running the SD-Backup program, ServiceDesk makes rather a pest of itself in seeking to persuade you it ought to be done. This, and all the pester elements we engineer, are done for your ultimate benefit -- based on what we've seen users suffer, by not doing things they ought to.
Regardless, RSS users do not need to be running SD-Backup. It's because the RSS system itself provides its own very robust backup elements, so others are not needed. Thus, such pestering in the RSS context made no sense. This release fixes that.
Another little change is, when RSS clients now connect for assistance, we'll be direct-alerted to the fact you're an RSS user. This will, in many cases, help to better direct our efforts (there have been cases, if you wish to know, where we're helping an RSS client with some issue in SD; we conclude the problem is "in the environment," and tell the user they need to take it up with their IT provider; oops, it's us).
"Department-Assigned" Added to the "Jumbo" Parts Label:
This is one that will likely interest only a very few, but if you have the need, you'll like it. If you use the Departmentalization feature, and if you'd like the underlying-assigned department to be listed on parts labels, it will now happen if you pick the "Jumbo" style Dymo label.
Upgraded SP-DispatchLink (Ver. 4.3.54):
Over the
years, a great deal of sophistication had been added into SBDL (stands
for SB-DispatchLink; it's our integration utility for ServiceBench) --
in particular for how it figures uploading of availability.
Among
such elements is a function slightly akin to "flowing-pipes," but it
happens without any setup by the user, and is between day-segments
instead of between zones.
Example:
Suppose that for a given zone you have allotted 5 jobs for morning, 5 for
afternoon, and 5 for all-day. On a particular day, you've
scheduled 9 for morning, 8 for the afternoon, and zero for all-day.
Thus, you have 17 total total bookings against 15 allocations.
Obviously, you're overbooked. SBDL has long been smart enough
(just as is the "All" view from within the SD's ZonePlanner form) to see
such overbooking, and to refrain from offering availability for any
segment (even though, essentially, you have zero all-days booked against
allocation of five slots, meaning, looking at that segment alone, it
might appear you should have five slots open there). Essentially,
where one day-segment area is overbooked, SBDL "flows" that "overbookingness"
(nice word, eh?) into another segment area. This is but an
example. We've added a number of similarly-sensible IQ elements.
Until this now-announced release of SPDL (stands for SP-Dispatchlink; it's our SBDL-equivalent utility for ServicePower), the latter did not possess this and a few similar elements of enhanced IQ. In other words, SPDL would, for the described example, look simply at the fact you've allocated five for all-day, you have zero scheduled for all-day, and would therefore offer five all-days as currently open).
Why was such added IQ not formerly there?
These added IQ elements were added into SBDL gradually over time, as (from experience) we realized various needs. Until recently, nothing jogged our realization that the same needed to be done in SPDL. Just about as soon as that realization came (it was last week), we brought it up to par.
Why was there formerly nothing to jog our realization?
Until recently, the online availability review, at ServicePower, was knowingly erroneous, so far as its ability to accurately reflect true availability values uploaded. Because of this, there was no easy/direct way for users to verify if values as uploaded were a good reflection of what they wanted uploaded, and to inform us if otherwise.
Regardless of explanation, if
you are using SPDL, please update it at once. You'll have better
availability-upload results.
Added QuickPic-Viewing Accommodation:
Recently we were troubleshooting for some users where, upon picking a QuickPic photo to view, the system indicates inability to download the picture. This is evidently caused by security elements in the user's system, which in some instances can be rather challenging to overcome. Sometimes, when you come up against a wall, it's better to go around, rather than to insist on going through.
Our solution in this instance is to offer an alternate mode of viewing.
By default, SD's QuickPic viewer first downloads the requested photo, then opens it in whatever installed application you have designated, within your Windows setup, to open .jpg files (typically this is some kind of photo-viewer app, such as Windows Photo Viewer). But, as my dad used to say, there's more than one way to skin a cat.
An alternate way to view most photos (including those of jpeg variety) is, simply, within your web browser (e.g., Internet Explorer, FireFox, Chrome, etc.). This is our method around the wall.
If something in your system stops the default method of QuickPic download (or if, perhaps, you simply prefer to view in your web-browser as opposed to a picture viewer), you can change from the default. The method is to simply right click within the JobRecord's instance of the QuickPic button:
At which point you'll see a dialog that looks like this.
Simply pick your preference, and your QuickPic photos
will be presented accordingly.
New Section in "Result-on-Dispatches" Report (Evaluate Performance of Office Personnel):
In the past two or three years, we have had increasing requests for reports to help managers evaluate the performance of office personnel. It's an area we've been weak. There are a number of exports you can do from the Alt-F3 form (and, on the basis of information in those reports, do some of your own analysis). There is also the CyberOffice Survey system, which does a truly superb job of helping you evaluate how well your call-takers are doing, in terms of making your customers feel splendidly delighted. But (and in rather stark contrast to the plethora of tools we have to evaluate technicians), we've not had a lot more to help you evaluate office personnel in more concrete terms.
Paul Manning emailed a while back with a particular concept. He said he's very fond of our Result-on-Dispatches Report (F11-->T-->D), for the abundance of detailed information it provides. He further explained he thinks some of his office persons may be lagging, particularly when it comes to pre-screening jobs in the effort to assure maximum probability of first-visit-completion. He suspects, but would like real-numbers confirmation before he lets anyone go. He looked at how this report lays out comparisons between techs (in regard to several measures regarding what ultimately happens on dispatches) and wondered if there could not simply be a similarly-included insertion for office personnel (on the basis, specifically, of which particular office person performed the Job/Sale transition on each particular job).
It seemed like a rather good idea, and so is completed in this release. Here is a snippet of the now-current report, with the newly inserted lines highlighted in yellow (they will be different for your company, obviously showing a list of your personnel):
Please forgive the fact many of the actual numbers here do not show
well. I pulled from the old data from my old service company (from
way back in 2001). At such time ServiceDesk was not maintaining
all data elements in the same way it does now, by which reason this
particular showing suffers. Yours should not.
Finished-Forms Protection Against Typing Too Much Text to Fit In Printout:
Most of the forms, as available from within the FinishedForms context (Alt-F4), include one or more scrollable text boxes. By nature, these boxes allow you to put in many lines of text. Because of this, it's possible a user might put in more lines than can fit within the allotted space of the underlying form-format when printed (whereas, on-screen, it is no issue). This release adds a feature to warn if your typed text infringes into this, good-printout-threatened territory.
Specifically, where this situation occurs the system will change the background color of the scrollable box to red, and a ToolTip (little message that appears when you move your mouse over) will appear as follows:
You remain free to type more or less text as desired.
It is not a club: just an aid to help you, when you're intending to
create an actual ticket image (whether "printed" to electronic format or
actual paper) as to whether there are two many lines to ultimately fit
in that context.
Option for File-Export from PartsPick Interface:
Many months back we added an option, via a simple button, to physically print a summary of items as listed in the PartsPick interface (Shift-Cntrl/F8). Recently, a client requested ability to use essentially the same summary via an Excel or similar file-based format. That option is now added. The old Print button, which had looked simply like this:
Now looks like this instead:
When you click on it, the Printer-Select dialog box newly offers the
option to Send-to-File. If you desire it, pick that option, and
follow the prompts. It's that simple.
Updated Method for Accessing QuickPics:
Overnight, last night, we re-configured the store-method for
the rapidly growing mass of files as connected with our SD-QuickPic system.
Based on how these files are now being differently stored, the method
ServiceDesk formerly used, for showing you the pics, had to be changed.
This release has the needed change. If at this point you try to open these pics,
but from an earlier version of ServiceDesk, you'll get nothing but a blank for the
picture. If doing the same via this release or forward, by contrast,
you'll get the same perfect result as always.
New "Panning" Shortcut for DispatchMap:
Each ServiceDesk client-business has a unique DispatchMap, custom-created to fit its own service territory. Almost all are scaled such that less than the entirety can fit within a single screen view. To cope with this, the system allows you to "pan," moving the view-window to change the portion of DispatchMap that is "exposed" at any moment.
Prior to this release, there were three methods to pan. First is by using the arrow keys on your keyboard (aka "cursor" keys). Secondly, you can move your mouse to near any edge of the DispatchMap view screen, watch for the cursor to change to a move symbol, then click (has the same result as punching the same-vector arrow key on your keyboard). Thirdly, you can roll your mouse scroll wheel (from virtually any on-map position) for vertical movement, or move to the right or left edge and scroll/roll for horizontal movement.
This release introduces a fourth method. For those of you that have particularly large DispatchMaps (meaning many panning steps are required to move across the entire expanse), this new method will be particularly appreciated -- because it allows you to skip over intervening pan positions, and go directly to the position of interest.
This method uses the DispatchMap's Mini-Map Inset, which you may or may not have enabled from the Settings form. If you do not have it enabled, we suggest going to your Settings form, to turn it on:
The actual method, in the new panning feature, is simplicity itself. Just right-click within the Mini-Map at the position you want your pan/view position moved to. Your view position will move there instantly (and won't "pass Go" while on its way):
If you did not know, by the way, you can move the
Mini-Map inset itself (also, the little job-burden pie-chart) anywhere
within the view screen you wish. Just drag with your mouse to move
it.
"Alarm-Clock Plus" Function to Assure Afternoon Send-Outs of Appointment-Reminder/Confirmation-Requests:
Several people recently asked for this. They explained how, whether based on emails, robo-calls or a combination, ServiceDesk's afternoon send-outs of appointment-reminders for the next day (these include requests for the customer to confirm) have become so very valuable -- with one downside. It is sometimes they forget to initiate the process, with big loss in benefit.
What was requested, essentially, is a reminder, within ServiceDesk, providing a "kick," more or less, urging an operator to initiate the process.
For context, we have not believed it is optimum for initiation of the send-outs to be entirely automated (i.e., set to automatically occur at a certain time each day, without user involvement). It's because these reminder/requests should not go out until such point in the day when you have the next day's appointments rather fully worked out. The time at which this is accomplished can vary. Thus (and as a matter of design), we've thought it made most sense that it's regular practice, each afternoon, that someone is responsible for finalizing the next-day's roster (at least so much as is possible), then that person initiates the reminder/request send-outs.
But, if users forget to do this, it's a problem. This release presents our solution.
Our first task, in creating this solution, was to create an interface where you can indicate how you want your alarm/reminder system setup. Turns out we already had an interface for setting other appointment-confirmation preferences. It was introduced a bit more than a year ago (see notes accompanying Rel 4.5.58), and was accessed via selection from within the DispatchMap's Cheat-Sheet:
While we could have made a new settings interface for our new purpose, it seemed sensible to keep all such related settings together, but with an important change. You may notice the above explicitly notes its settings are "local" (i.e., particular to the station where set). There had been no reason for this aside from ease in programming. The new settings definitely needed to be system-wide. For this reason, we have superseded the above with a new interface. It incorporates the same three settings-options as were above available (while making them system-wide rather than merely local), and adds a much larger section for our new matter of concern. This new interface is accessed from the Settings form (Ctrl-F1), via button as shown here:
Here (with moderate annotation), is what the new interface looks like:
Please notice the old three settings preferences are on the left (all that's truly new is on the right).
As you can see, the interface allows you to setup successive reminders for up to three different persons. Part of our logic is the first person might happen to be out of the office (or maybe sleeping) on a given day. If so, the second person provides a backup. Ditto between the second and third persons.
As you can also see, there is provision for even further backup. You can set it so, if no human responds at all to alarms as potentially setup for them (by, of course, manually initiating the reminder/confirmation-request send-out), the system will indeed go ahead, and automatically initiate the send-out, entirely on its own (this is the setup that's done in that bottom area).
We suspect some users will be tempted to forego human reminders, with choice to depend entirely on automated send-outs. We'd be reluctant to take this choice, for a couple of reasons. One is it's likely optimum to initiate send-outs just as early as you are confident tomorrow's schedule is reasonably finalized. If you're at that point earlier in an afternoon, it is beneficial to do it at that earlier-in-the-afternoon point. At the same time, if you're not yet reasonably finalized, it's better to wait until you are. A trigger that's wholly timed and automated cannot produce this flexibility.
We suspect others may choose to depend entirely on the human reminders, leaving the machine-initiates option un-set. We'd be more sympathetic with this choice. However, if the machine-initiates option is set for a significantly-late time (at or after office closing hours), we believe it is arguable that it's better to have the reminder/requests go out even if automated (i.e., as opposed to not going out at all.
If it is not clear from the interface, by the way, no alarms will sound for anyone if, by the time set for that alarm (or for the computer itself to initiate a send-out, if so set), a send-out has already occurred. Thus (and to make it more clear), if person A responds by initiating the send-out, persons B and C will not be alarmed; nor will there be any automated initiation.
The actual alarm/reminder is via a box that will appear on an applicable user's screen (dings several times as it initiates), and looks like this:
This alarm will appear on the designated desk for one minute, then extinguish for one minute, then re-appear and repeat the cycle. The cycle will continue until either the send-out process initiates, or the day ends. It will not stop simply because a second or third person's alarm period arrives (though if a second or third person initiates the send-out, that will indeed stop it). If you are wondering, you can set as many or few, among the available alarms, as you wish.
You'll notice there is also a section where you can designate the particular days of the week in which the alarm-potential will be operative. There is a secondary effect in days selected. Suppose you have days set as per the default/example. You also have the computer-initiate option set to go, and on Friday no user initiates, leaving SD to initiate itself. After initiating send-outs as applicable to Saturday's roster (which may or may not be empty), SD notices Saturday is not checked for applicability of this new assure-send-out feature. Based on this, it figures it better initiate for Sunday as well, and so does so (likely no appointments for Sunday, so that may have little effect). It then notices Sunday likewise is not checked for applicability, and so self-initiates the the next day's roster, which of course is Monday's. Thus we achieve the logically-desired consequence that an auto-send as managed on Friday will actually send for appointments as scheduled for Saturday, Sunday and Monday (assuming days setup as in the example; you could setup otherwise if desired).
Please note the old settings preferences (those that prior-existed, and have been moved to the left-hand side of this new venue) will need to be reset here, if you desire other than the default settings.
We hope you enjoy this new enhancement, and make it
profitable.
Survey-Limiter Option:
If you're not using the SD-CyberOffice Survey system, you should be. Its power is awesome. The technician finishes a job (as registered within SD-Mobile), and within moments the customer is sent an email that expresses gratitude for the opportunity to be of service, and asks if the customer would not mind completing a super-quick, four-question survey (it's the "on-a-scale-from-one-to-ten,-pick-a-value" kind). The survey is designed to give you enormous information on the basis of just those few questions, plus provides an excellent opportunity for you to turn things around on those rare occasions when your customer was less than happy (an optional comments section also gives you a source for very useful and pleasing kudos).
Anyhow, among those who've implemented this survey system (and, of course, love it), some have had a little issue. In particular, it is those doing service for Whirlpool. The things is, Whirlpool does its own surveying. When customers have already been surveyed by you, then get surveyed by Whirlpool too (whose surveys are not so blessedly short and quick), there is concern some degree of annoyance might arise, causing your customer to report on the Whirlpool survey less favorably than if they'd not already answered yours.
That's where this new option comes in.
In the ServiceDesk QuickEntriesTemplate (Shift-F1, pick a client, then click on "Edit"), there is a new checkbox:
There is one more thing. You'll need to update
to the current release of SD-MobileLink (Ver. 1.4.128). Even
though the survey system is a CyberOffice feature, it happens to be the
SD-MobileLink program that sends the email invitations (it's because
it's downloading of the tech's completion PVR, an SD-MobileLink
function, that triggers such sending). Prior versions of
SD-MobileLink are not programmed to look to see if, for any given
client, you have checked the above box in ServiceDesk, and to refrain
from sending the survey in circumstances thereby made applicable.
SD-QuickPic ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !:
Yeah, this one is pretty big.
We've introduced our first smartphone app.
It's designed to harness something smartphones do particularly well: taking pictures, and forwarding them elsewhere via the internet.
For background, for sometime there has been a large and growing movement among servicers to have their techs photo-document an array of matters connected with each job. First among such elements is the model/serial plate on the machine being serviced. We have heard of numerous instances where a manufacturer claims a provided mod/ser combination is not valid, and rejects the claim. A picture is then provided, and the argument ends. Another photo purpose is to document that a machine and/or the floor on which it stands were already subject to damage, before the tech began working. There are other purposes as well.
Until now, companies that extensively use photos have implemented somewhat clumsy methods to get the photos, as taken by each tech, from the techs and into ServiceDesk. One method, for example, is to have the techs upload their pics to photobucket (an online sharing site). To make this work, the techs have to manually flag each pic to indicate which job it's involved with, and someone in the office has to go online, find all the new pics, download each, then manually attach to their applicable jobs. It's a significant amount of work. We figured we could eliminate all such extra effort -- and facilitate more pictures as well, by making the underlying processes much easier.
Enter SD-QuickPic, our new smartphone app.
For now, it's exclusive to the Android platform. We plan, ASAP, to add for the IOS platform (Apple) as well.
Here's how it works:
The tech first needs to download the app from Google's play store (same as downloading any other app into one's smartphone). He can search on the phrase "sd-quickpic" and find the app-download easily, or here's a link. Then he needs to run it. Initially, there's a place for him to put in his and your company's SD-Mobile credentials (same as within SD-Mobile itself).
The app runs, and shows him a list of his jobs as applicable to the present day. It also shows if there are prior pictures associated with the underlying machine to be serviced (i.e., the connected UIS). If so, he can click on the reference to view such prior pics.
If he wants to snap a new picture as connected to any job, he simply taps that job's reference, then snaps the picture. He can then type in a description, if wanted, and save/upload the picture.
The pics are uploaded and maintained for you on our array of servers. We've provided buttons in two places, within ServiceDesk, via which you can access these pics. The first is within the current-JobRecords form, which will provide a list of such pics as connected with that particular job:
The second is in the UnitInfo form, and will provide a list of pictures as applicable to this particular machine as represented in the loaded UIS:
There is also a new release of SD-MobileLink now available for download (Ver. 1.4.127). When creating the narrative entry in the JobHistory that results from a tech's SD-Mobile-based PVR, it will include a notation indicating if he added pictures during that visit, and this will act as a hyperlink (if double-clicked upon) to the particular pics he took on that visit.
(Small caveat: this notation will arise only where pics are snapped and uploaded before the PVR is downloaded by SD-MobileLink).
We have been working toward this offering for sometime, and are very excited to finally offer it. Naturally, there is a fee. It is only 4 cents per pic uploaded. The app itself is free.
One note: There is a bug in the latest Android release
that, on first, post-install run, fouls-up the step from picture-snap to upload.
If your tech encounters this, he should simply close and re-open the app.
It should solve the problem.
ADDENDUM: Since release earlier
today, we've discovered some instances of Android are encountering significant
operational faults. If your techs encounter this, please ask them to click
on the "Report" button. This sends information to our Android developer
that will assist him in troubleshooting.
Better Pricing from SmartParts data in Mobile -- Especially for Canadians:
Our SmartParts lookup system (as present within ServiceDesk and as a stand-alone program) has long had a feature where you can load in pricing that's particular to a specific participating parts vendor. We've invited virtually all the vendors to participate, but to date only Reliable Appliance Parts has done so. Thus (and, in present effect) you can load in pricing specific to Reliable (this is opposed to the more generic pricing that is otherwise offered).
This Reliable-pricing feature was enhanced more than a year ago when we added an option to add in Reliable-specific pricing for Canada, as opposed to the U.S.
Within SD-Mobile, we offer a selected portion of the SmartParts lookup database. It's applicable when the tech is typing a partnumber in either of the special-order boxes on the PVR page. It has lacked the Reliable-specific option that exists in ServiceDesk and in the stand-alone version of SmartParts. In other words, it offers the generic underlying price-points only (to be very clear; these are foundational prices, your own applicable markup scheme has always been allowed, regardless, to vary therefrom).
A number of Canadian users, in particular, have wanted
to have Reliable/Canada-specific pricing in the Mobile context.
That (along with Reliable-US pricing, if optionally desired) is what is
now offered. Full details are in this day's post as made in the
SDM-WorkDiary.
Improved Verbiage in Confirmation Emails and RoboCalls:
Recently a user told us his customers, on receiving an appointment confirmation request (whether by Email or RoboCall), were sometimes uncertain whether the indicated time-frame referred to AM or PM. For most indicated time-frames, the AM/PM context is obvious (who could doubt, for example, that an expectation for the tech to be there within the "12-3" time-frame refers to PM"). For some other indicated times, however, there truly is ambiguity (what is more likely the intent, for example, if the time-frame reference is "6-9"?).
We figured this should be addressed immediately, and while we were at it decided to improve the involved language overall, as relating to both the day-description and the time-frame description. Our goal was to make both descriptions more conversational in tone. Thus (and to provide some examples), time-frame descriptions have changed to convey to your customer as follows:
Old |
New |
7-10 |
between 7:00 AM and 10:00 AM |
9:30-12 |
between 9:30 AM and 12:00 NOON |
11-2 |
between 11:00 AM and 2:00 PM |
2:30 |
about 2:30 PM |
2:00 AM |
about 2:00 AM |
You might note the system is using the same AM/PM assumptions as used within SD itself, and if you want to override those assumption in your time-frame indication (as you setup the appointment), you simply need to add an explicit AM/PM designator, per standard practice.
Day-descriptions have also been changed for better conversational tone and descriptiveness:
Old |
New |
Saturday, 1/26 |
Tomorrow, Saturday the 26th |
Monday, 1/28 |
Monday the 28th |
Friday, 2/1 |
Friday, February 1 |
Please note the old notations were particularly bad for RoboCalling, for the voice-synthesizing engine would translate, for example, "Saturday, 1/6" literally as "Saturday one slash six" (in other words, this is precisely what your customer would hear). It worked, but made for a somewhat less elegant user experience. For the customer to instead hear "Tomorrow, Saturday the 26th" is obviously much better.
Please also note we've built some IQ into the language. The prefix "Tomorrow" is inserted if in fact the involved date is tomorrow, but omitted otherwise. The month reference is included if the appointment is in other than the current month, but is omitted otherwise. We think, all-in-all, it should make the interaction seem a bit more human-like, for your customer.
Some Fixes for Inclusion of Tech Picture:
Two entries back/below, you'll see where we added an
option to include the involved tech's picture in confirmation emails.
Pretty cool, but it turns out there were some circumstances where it was
not working as intended. Those flaws have been fixed with this
release.
An Alternate Look at Recalls:
For many years, we have offered two robust reports to give you an extremely solid basis to measure the rate at which your techs are doing work that results in recalls (F11-->T-->B). The two use alternate methods, either of which may be optimum for your circumstances, depending on your mode of work (please see pages 23 to 28 of our ReportsHandbook for details).
By nature, these reports are designed to flag work that was in some manner deficient, so as to result in a recall later on. Because of this, the reports by necessity must be looking at work that is at least some distance in the past (i.e., so as to have allowed time for the subsequent, "hey,-it's-still-not-working-right" requests to arise). If you try to measure this factor without allowing for sufficient such intervening time, you simply do not get a good measure. It's the nature of the beast, and given that fact it is always impossible to have a good measure of recall-avoiding performance that is very near to real time. To re-state the point, that measure can only be assessed at a moment where it's receded some distance (at least a couple of weeks) into the past.
There is, however, another measure of potential interest, and it's one Steve Blaisdell at Action Appliance called about yesterday. It's to know, simply, how many jobs within a more recent period (say last week) happened to be flagged as recalls. The key difference in this interest is we are not seeking to measure quality of earlier work (i.e., whether the earlier work led to recalls); rather, we are seeking, simply, to know how much of our current work happens to consist of the recalls themselves. To state it another way; in the traditional reports we are seeking to measure the blameworthy work, which later led to recalls. Steve wanted a measure for the later, fix-it work itself.
Though it would certainly be possible to make a dedicated report for this purpose, sometimes I can deliver a needed result faster, via a lesser means. In this case I've added a new field to the "Export Customer Data" form's "Scheduled-Jobs Report Type-1" (Alt-F3-->1). In a nutshell, you can run that export for the period of interest, then sort the result by the new field (it's the last field, and is labeled "KeyWordDsgntdAsRecall?"). This will provide a quick count of the quantity of jobs within the period that fall into such category, as compared to the quantity that do not.
If there is sufficient demand for it, we can make a dedicated report (to direct-provide these comparisons) at a later date.
Other Improvements:
As always (and as you can see by the Version-Number
changes) there have been many and miscellaneous other improvements, of a
nature that do not really require separate mention here.
Tech Pictures May Now be Included in Confirmation Emails:
Have a look:
The concept is obvious. Your customers will feel more comfortable (and even more impressed with how advanced and caring your operation is) when you provide a picture of the tech you'll be sending their way.
We have added a section in the CyberOffice Handbook which details how to add these pictures (in fact, we have done a massive updating and improvement in that handbook overall). The section which details how to add pictures for your confirmation emails begins at Page 19.
We must here provide one caveat to the instructions you'll find in the handbook. It instructs you to use your my.rosssware.net login to post the desired pics. Turns out that particular element in the my.rosssware.net interface is not yet ready. However, there's an immediate way you can upload your tech's pics. Just email each (with name format as specified in the Handbook) to techimages@rossware.net (please make sure it's only one pic per email; if you place in more than one per email it will not work; also, please assure for your filenames you follow the case-convention as specified in the main instructions).
New "Post-Completion RoboCall" Feature in SD-CyberOffice:
Several users asked for a system to automatically make RoboCalls to customers after the job is complete. There are a few different ideas as to what kind of verbiage these RoboCalls might encompass, but the major notion seems to involve something along the following lines:
"This is a message from XYZ Appliance Service, and we want to thank you for granting us the privilege to service your machine. We hope everything went superbly, and, if not, that you will please let us know so we can amend. Please also know that in the next two or three weeks you will be contacted by Whirlpool to fulfill a survey on their behalf. We hope you can view us favorably at that time."
We've made the system so you can create your own scripts for this purpose, and in fact employ different scripts depending on whether it's a COD job, or any particular third-party payer. You can also control the timing for when the calls go out.
Much as with our new tech-pics option for confirmation emails, there is also a just-added instruction set, for this feature, in our newly-revised CyberOffice Handbook. Those instructions begin at Page 16.
As another parallel, this one too has a caveat regard where the instructions tell you to use the my.rosssware.net interface. For the time-being, you must contact our Josh and ask him to add script blanks for you to there edit (soon the script blanks will be provided automatically).
SD-CyberOffice-integrated Survey System:
This is one is really big. It's really big.
While working to add documentation on the two new CyberOffice features above-described, we discovered (to our horror) we'd never made a general announcement on this awesome survey system, in spite of the fact it's been operational for almost a year. So, here is our belated announcement.
As intimated, this survey system is awesome!
The general concept is, after a tech completes a job, the system sends a thank you that incidentally asks the customer to do a very quick (it truly is very quick) online survey. The survey is based on the NetPromotorScore method, which is nearly magical in its ability to glean maximum useful information with minimal intrusion of inquiry (just four, please-rate-on-a-scale-of-one-to-ten questions). Tanner Andrews gets credit for leading us toward this method.
Benefits in using this system are enormous. It assures your customers you care. It informs you (and down to the individual level) how well both your call-takers and techs are doing in making customers happy. It gives you direct commentary from your customers (besides the four questions, there's a comments section where they may optionally type). In some instances, for example, customers will have been so impressed as to write glowing testimonials (which makes you feel good, and you can also use in ad copy). In some they will have been disappointed, and the notice as provided by their response provides an opportunity for you to turn that disappointment around.
If you're not using, you have no idea what you're missing. It really is stupendous. Start using it. You'll be glad you did.
New Rossware-MySql-Server Checking, and HyperLinks in ServiceDesk "About" Form:
Recently, as we've been working to upgrade redundancies, performance and reliability in our system of co-located servers (they provide data services for SD-CyberOffice and SD-Mobile, and are also the foundation for our hosted websites and hosted servers), we've encountered some outages. In part, these have been transitional hiccups (working toward greater reliability, the transitional state and essential learning curve have made for temporary decreased reliability).
Aside from being frantic to fix ASAP when these events have occurred, we've noted one of the main elements for stress (at least among many users) has been uncertainty as to whether the problem is on their end or ours. So (and regardless of the fact we strongly hope to avoid any further outages), we've added a mechanism to make it easy for you to tell.
Essentially, we are employing a second co-located server, that is independent, outside and separate from our main bank that's housed at a facility just a few miles from us (it's located prox 100 miles away in Portland). It continuously monitors our main bank, and will independently report on whether there is an issue. We've actually had this going for some time, so as to inform us if there's a problem (it will wake us in the middle of the night if so). Now we've made it so you can also access its information.
In the ServiceDesk "About" form (first option under "File Functions" in the Main Menu), there's a new hyperlink:
When you click on the new checking link, you'll get an immediate report, such as the following:
As you can see, it not only tells you the simple status; it also asks if you'd like to view a detailed performance report. It's an online analysis of our server performance (there's no cheating there, really), and you will likely find it interesting.
In addition to allowing you to volitionally check, we are now also employing this external-checking ability to modify the reports that are given to you when connection problems occur. Instead of the system simply telling you it's failing to talk to Rossware's server (and maybe it's a problem there or maybe it's on your end), it will first make a behind-the-scenes determination via that external monitor. If this shows it's on the Rossware server end, it will tell you so unambiguously. It will even distinguish for you if it's a scheduled-maintenance down (these do happen from time to time), or otherwise. If otherwise, it will further assure we are on the matter, just as soon as we are (which generally will be within a very few minutes of the occurrence, given systems that actively alert us).
These "Enhanced Notice" improvements are in this release of ServiceDesk, and will be in the next releases of SD-MobileLink and SD-CyberOffice.
Enhanced "Cloning" for Planned MasterPartsPlan Quantities:
In the last release (see just below) we increased the max potential quantity of specialized stocking plans from 6 to 60. Almost immediately, a related augmentation was requested.
There has long been a mechanism where you can populate quantities for any particular specialized Plan by cloning from quantities as setup under the standard Truck plan. The general idea is, you can rapidly/easily populate a foundation of plan quantities via the clone method, then refine where different quantities are particularly wanted as different for your new plan:
However, more flexibility was requested. Maybe, instead of cloning from the standard Truck plan, for example, you want to clone from a particular other specialized plan. Or perhaps, instead cloning from another Plan, you want to set your plan values according to actual inventory quantities as presently exist at a particular location.
This revision adds such flexibilities. Nothing is changed in terms of how the cloning process invokes; it's merely an enhanced dialog. Thus, when you click on the asterisk next to a Plan reference in the MasterPartsPlan's Supplemental-Info form, you'll now get this:
If you pick the first option, you'll be
presented a list of all other Stocking Plans, and allowed to choose from
any. If you pick the second, you'll be presented with a list of
all Inventory Locations, and allowed to pick from any. It's pretty
much that simple.
EUREKA!!!!
HALELUJAH!!!!
SUPREMO FANTASTICO!!!!
Increase in Quantity of Unique Stocking-Plans:
The exorbitant fanfare in the title is intended to reflect how badly some of our users have wanted this, along with the fact some have have wanted it for a very long time.
The expansion was slow in coming primarily because I envisioned it as necessarily entailing a very major overhaul (involving core re-design elements) of the complete inventory system. It's difficult to fit such a major re-work into our development agenda.
About ten days ago one of our users (Brenda at Fields Appliance) presented a very factual and convincing case which vividly demonstrated how dramatically inadequate, for their purposes, has been the 8 unique stocking-plan max that has existed to-date (standard Offc plan, standard Trk plan, plus 6 added plans). Though I'd already felt significant weight to provide the expansion, the vividness of Brenda's demonstration served to get my mind working much harder on the task. As it worked in this fashion, I managed to conjure a strategy for increasing the quantity of stock-plans available, sans any major overhaul. This made it practical to do in the short-term, rather than long-term. Hence, the improvement is offered now.
Our old ManagePlansAndLocations form (Ctrl-F10-->H-->L) looked like this (where the area on the left is used to define up to six beyond-base stocking plans):
Our reinvented form looks instead like this:
As you can see, the area where you can define add-on stocking plans is considerably changed. Even on the face of it, you can see the quantity of potential add-on plans is increased to at least 12. In fact, with use of the scroll function (you can use the standard scroll method, or the scroll wheel on you mouse will work fine too) you can create and access a full 60 (ten-times more than before). We doubt if anyone will need a larger quantity than that.
The ManagePlansAndLocations form is not the only place the change was needed. It applies as well in the Supplemental-Info window, as tied to the MasterPartsPlan interface:
Old | New |
|
|
This is, of course, where you set the minimum for each stocking line item as corresponding to each of your specialized stocking plans (however many you happen to setup). Again, the scroll function allows you to access the entire array of up to 60 unique/added plans.
New Export for InventoryItemsOnOrder:
As any experienced SD user knows, we have two, rather separate systems for handling parts: the PartsProcess system for special-order parts, and the InventoryControl system for stocking parts. Each is tailored for the particular needs as applicable to its respective context, and they are very different. A major historical difference is that, while the PartsProcess system has always been designed to keep very careful track of items on order and awaiting arrival, in the InventoryControl system we historically considered this a less essential objective.
A significant departure from this laissez faire approach (in regard to inventory items on order) was created some 13 months ago (see entry accompanying Rel. 4.5.45), when we added a feature that keeps behind-the-scenes track of what's on order, and when you go to formulate a new order informs you, in regard to any item that may need to be ordered, of any order that's presently pending for that same item (again, please see the prior release notes).
As we added that enhancement, we contemplated it would be but the first step toward creating a more full-fledged, pending-PO-tracking element, as part of SD's InventoryControl system. This release provides a tiny further step.
Specifically, we've made the Inventory-Items-On data much more readily visible. Prior to this release, the only way to see such data was as it was reflected when going to place a new order via the F10 form. We've now added a simple export function, that allows you to see it in full:
We recognize this export will facilitate a somewhat
less-convenient visibility than might be optimum, and lacks any facility to edit
the actual source data as present within ServiceDesk. If users express the
need, we'll no doubt expand to such capabilities in the future. In the
meantime, a simple export like this can be created with a much smaller
programming investment than can a full-fledged (and editable) user interface.
New Fields in "Usage Rates" Report:
Tanner Andrews (Andy's Appliance Repair, Lincoln, NE) works very hard to assure he's stocking each of his trucks in the most optimum manner possible. His was among the voices that drove us to create our "Usage Rates" Report (Ctrl-F8-->U) way back in October of '08. Recently, he wanted better definition than this report has prior provided. Specifically, we wanted to easily see not merely the frequency of each part's usage for his operation as a whole: he wanted to easily see usage for each location (so as to better define which locations should sensibly be stocking which parts).
It made good sense, so we have delivered.
If you run the main report, the portion that displays onscreen will appear just the same as before. But if, after the main report is displayed, you click on this button over toward the right:
the resulting export/spreadsheet will have several new fields, not prior provided. Specifically, it will have as many more columns as you have different inventory locations. Each such new column will indicate, for each part-number/line-item listing, the quantity as used by that respective location.
The concept of including these columns may seem pretty obvious and basic (to such an extent to make it seem embarrassing they were not already there). Sometimes it takes a really smart guy like Tanner to realize where something so basic has been missed. Thank you Tanner.
New "Print" option for same content as prior available in Large/Detailed Email of Dispatches:
Based on the fact we so strongly consider SD-Mobile as the mode via which modern service offices should be dispatching jobs, we are less than anxious to keep pouring resources into updating and improving older and more legacy methods. However, we're not always good at saying no.
There are a plethora of dispatch methods that arise when, from within the DispatchMap, you click on a tech's name at the top of his list of jobs. Among these is one designed to send the tech his entire roster (including rather exhaustive associated details) in a single/large email. We purposely optimized text within this email for -- well -- the email context. Back to that list of options, there is also one designed to locally-print the tech's roster, similarly with exhaustive detail (but here optimized for printing).
Lo and behold, if there weren't some users who preferred the email formulation of contents, but wanted it in a printout, rather than an email. As we said, we're sometimes not good at saying no.
So, right on the face of the dispatch-methods menu, you may now see subtle changes in wording, to indicate our newly enhanced flexibility:
Old | New |
|
|
From this point forward, when you click on the beloved "E" option, instead of simply being presented opportunity to email, you'll instead get the Printer-Select dialog box, configured to allow specification of email or printing:
It should at first default for email, which means if you want printing instead you have to check that as the alternate function.
Restoration, as Option, of Old MailList-Maker Method:
When, just two weeks ago (see entry accompanying Rel. 4.7.5), we did a complete rebuild of machinery that constructs a mailing list for you (making it dramatically more efficient), we felt very good about it. Alas, no good deed goes unpunished. It turns out the old method had one distinct virtue that did not survive the new improvement: it allowed you to directly select how far back the system would look, among completed JobRecords, for names to insert to the list.
Our old and inefficient method was conducive to that kind of selection. The new method is not. Given this, we've added a dialog, when you choose to make a MailingList (Alt-F3-->M), as follows:
So, you can now revert back to the old method, if
wanted for its one virtue.
Multiple New Functions for Auto-Integration with ServiceBench:
Yes, this venue is typically used to describe ServiceDesk-specific improvements, as opposed to those made in complimentary apps. However, since so many of you also use the SB-DispatchLink utility (SBDL), and since we've made rather significant improvements there, this seems like a suitable place to announce.
Only some three months ago we added two new elements of information that may potentially be auto-uploaded to ServiceBench, via SBDL (that time we announced via email to SBDL users): ServiceDesk JobRecord HistoryNotes and direct/separate close-transactions for completed jobs:
Since then, we've been asked for three more additions to our SB-uploads roster: (1) direct notice when job is re-scheduled; (2) direct/live-informing when a tech arrives and/or departs from each job; and (3) direct notice of each event when a message is left for a customer (or similar significant to job-progress event).
It appears, evidently, NEW is campaigning hard (and perhaps other entities are as well) to maintain a live and real grasp of how each job is progressing.
Regardless, we have added each of these new transaction functionalities into SBDL (though not all show as discrete options within the SBDL interface):
Here is a specific explanation for each of these options, as now setup:
Looking in the first of the checkboxes as now configured, you'll see it reads similarly (though not quite the same) as compared to what was added in that position three months back:
From Three Months Ago | New/Current |
![]() |
![]() |
Formerly, if you had the above-option checked, JobRecord HistoryNotes would be added with each sub-status upload. Specifically, they'd be added as a single (and typically large) block of text, within a Comment section that was directly appurtenant to the sub-status update itself. In other words, it was simply part of the status update (a mere comment appended to the same), and was not a transactional-upload event in and of itself.
We discovered, with such notes provided in this fashion, they were not reaching the eyes of persons interested in seeing such details (such as NEW personnel). Upon also learning some users were being pressed to log into their ServiceBench online interfaces to manually enter notes each time they talked to (or left a message with, etc.) a customer, we decided we needed to upload JobRecord history notes (and with each note as a separate item) directly into the same place users were being asked to do it manually.
So, if you now have the first sub-option checked (as above illustrated); it will invoke a rather different underlying action, as compared to before. Instead of uploading the entire JobRecord historical narrative as a mere add-on comment with the status upload, it will instead upload each discrete entry, as added to the applicable JobRecord history since the last prior update. It will upload each such new item individually, and using a dedicated ServiceBench Add-Comments transaction as made for the purpose. In result, these notes should now be placed precisely where needed for appropriate visibility by underlying ServiceBench clients (e.g., NEW).
Now we focus on a checkbox option that is indeed totally new, with this morning's release:
As its wording suggests, this one will upload to ServiceBench notice whenever you change an appointment (or make a new one) on an applicable job (i.e., one that was dispatched to you by ServiceBench). Much like that above-described "Comment" upload, it's being done via a dedicated SB transaction we'd not formerly been employing.
Though the third status/sub-option checkbox is not new with this release, we'll nevertheless provide some contextual explication (in particular, for any who may have missed the explanatory email from three months ago):
Normally, SB-dispatched jobs are put to bed ("closed") via the claim-filing process, as done from within ServiceDesk. The problem is this sometimes does not occur in the intended fashion. In particular, we've learned for some servicers it's quite common to have a job dispatched by Lowes, with a claim being made against Whirlpool. This fails to close the Lowes job. This option (as added three months ago) is designed to assure closing occurs, regardless. Indeed, it should assure closing after a JobRecord is moved to the archive, whether a claim was involved in any manner.
You may notice there are no checkbox options for turning on or off what we described, early in this post, as another addition to the arsenal of status-upload related functions: direct/live-informing when a tech arrives and/or departs from each job. There is no sub-checkbox for this, because this function is not sub-optional. If you have the main/general "Uploading of Job Status" frame checked, general status changes will be uploaded, along with when the sub-status changes because a tech has arrived or departed from a job. We simply do not contemplate anyone will want to upload status generally, and not want to do the arrive/depart sub-status change as well.
Of course, it's also true that if you do not have your techs using SD-Mobile (or using it but not doing it live as per design intent) there will not be a basis to do the live reporting of their arrivals and departures. Uploading of those events depends on the system itself having due notice.
Please be aware, BTW, these new functions, that are
optional, default as unchecked. If you want the functions to
occur, you need to check the applicable boxes.
Improved MailList-Maker Export:
Hit Alt-F3 in ServiceDesk and it brings up what was originally called the MakeMailList form:
It was called that because, originally, its only function was to produce the output that's now but the first among nine (the other export options have gradually been added).
Anyhow, that oldest and original function was, until just prior to this release, very creaky -- to such an extent that, for a large database, it could take many hours to do its task. The plain fact is the underlying program code was doing the needed work in a very inefficient manner, and this is a place where efficiency counts. Part of what's involved in constructing a Mail-List export is winnowing through the entire mass of JobRecords, to assure the output has but one line-item for each actual customer (and not repeated line-items where you've done repeated work for that customer). We also want to assure there is no more than one line item for each physical address. This prevents us, for example, from sending multiple mails to the same household if different persons there ordered service from us (say once by the husband, and once by the wife). It also prevents us from sending a mail item to both a former owner/resident (who's long since moved elsewhere) and the current resident too. The system is configured, for any given address, to export a line-item only for the name as most-recently associated with a given address.
The old method as underlying this export engaged in a painstaking process of checking each potential addition, within the range of all prior additions, before adding it into the export. It was logical, but with many tens of thousands of records could result in a very slow progression. It also was limited to producing no more than 32,767 actual output items.
Our improved method uses a more clever algorithm to achieve the same result, but in a much more efficient manner, meaning for large data sets it will run very, very much faster. It also overcomes the 32,767 limit.
Added "Items-Returned" Figures to the PartsProcess Form's Acquisitions Report:
A little more than a year ago (see notes accompanying Rel. 4.5.34) we added the Acquisitions Report (Ctrl-F8-->Q). It's purpose is to itemize, by vendor, the cost and quantity of items purchased within a defined period. Recently a user requested visibility into quantity and value of items returned. This release offers the first step.
What we've done, substantively, is to simply add a couple of new columns to the Acquisitions Report. One indicates (again, itemized for each vendor) the cost of items returned, and the other the quantity.
There are some limitations in this initial offering.
So far, we're tallying special-order returns only (i.e., items managed
as inventory are not included). Also, there is a little bit of
fiction in terms of applicability to the date range. The return
tallies are based on the same criteria (for the parent special-order
request fitting the specified date range) as are the main entries.
This is in spite of the fact the actual return dates may (likely are)
different, and dates of any credits received are likely more different
still.
New Option for No-Visit Pseudo-Appointments:
Approximately five months ago (see notes accompanying Rel. 4.6.5) we made it so "naked" appointments (i.e., ones direct-created within the F6 form and without any connection to an underlying JobRecord) port to techs in SD-Mobile (as reviewed in those notes, it's pointed out that while it had always been possible to create such "naked" appointments in ServiceDesk, prior to that improvement they had not shown for techs in their SD-Mobile interface).
We mention the above for context and distinction (and, yes, I am still sufficiently juvenile to enjoying saying "naked").
Our present new feature, instead of involving non-job-tied "naked" appointments, involves a new kind. Unlike the animals just discussed, these are tied to jobs, but (and regardless) do not involve any real intent to meet with a customer. Rather, they involve what we'll henceforth call pseudo-appointments (for those of you who do not while away your hours memorizing How-to-Expand-Your-Vocabulary books, pseudo means fake, pretend, not real).
Why would you want a fake appointment -- and as tied to a specific job?
The reason is simple. It's to serve as a device that prompts for one or more needed actions on that job, but in situations other than where the customer is expecting the tech to be knocking on the front door.
For example, suppose, based on a WipAlert, you notice a tech was at a customer's home two days ago, and was supposed to research something to further the repair, but there's no evidence he's done it. Solution? Create one of our new pseudo-appointments. It's a way of prompting him to do the research, and booking a time-slot for him to do it within.
You can use these new creatures for any such (or similar) purpose. Best of all, your techs are permitted (even expected) to do PostVisitReports on them (in this context you'll need to think of such PVRs as as pseudo-PVRs), which nicely accommodates things like resultant creation of part orders, or of new real appointments, etc.
So how do you make one of these new pseudo-appointments?
It's pretty simple. In the F6 form we've added a new column of characters, on the very far left. The characters are simple checkmarks. Every standard appointment (even a "naked" appointment) has one:
These checkmarks denote simply that the appointment is not one of our new animals. In other words, it's not a pseudo-appointment. It is a "real" (or at least a "naked") appointment.
Given the above, if you want to create a new animal, you simply need to uncheck that box. It's default state is checked, which signifies "I am a real (even if possibly 'naked') appointment." Simply uncheck to indicate otherwise.
What are the consequences of unchecking?
A major reason this project has been somewhat long in coming is because there are a plethora of contexts within which a pseudo-appointment -- if it's going to be correctly treated as such -- must be treated differently. This plethora meant a lot of work, seeking to make each such context appropriately different. Here is a partial listing:
Historical notations (as made in each applicable JobRecord when an appointment is created) are changed as needed to reflect this different kind of "appointment."
Within the DispatchMap, the display of
pseudo-appointments is altered, to make it visually apparent they
are not true appointments with the customer. This alteration
consists of changing the display color (of the applicable list-item
reference) to a semi-feint grey:
On making this change, we realized it would be sensible to display
the old naked-appointments with the same visual distinction, and it
is now so.
Similarly, it seemed appropriate to refrain from adding these pseudo-appointments to the count of actual/true appointments as displayed in the DispatchMap, so (and in common with naked-appointments) they are withheld from that tally. On the other hand, if you decide to use an above-zero JobCount value for any such animal, it's important to include such JobCounts in the JobCount tally, and that is indeed done as well.
Still within the DispatchMap, while it seems appropriate to show pseudo-appointments as applicable within each tech's list section, it does not seem appropriate to show them within the graphic area. That distinction is indeed made.
Continuing within the DispatchMap, each of its contained methods for conveying dispatch-list info to the tech (as offered when you click on a tech's name at the top of his list of jobs) needed altered to make explicit, in regard to any pseudo-job, that a pseudo-appointment is what's involved, and not a real appointment where the tech is expected to drive to the customer's home (we noticed while doing this work, incidentally, that the old Naked-Appointments were not prior being including in these various outputs, and this was simultaneously addressed). There were no less than 12 different outputs that required significant modification in this category.
Continuing still within the DispatchMap, the route integrations with MapPoint and GoogleMaps needed altering to assure pseudo-appointments would not be included in their work.
Finally within the DispatchMap, the Confirm-Appointment-with-Customer functions (via Email and/or RoboCall) needed altering to assure pseudo-appointments were not included in their operations.
Outside the DispatchMap (but still within ServiceDesk), each of the tech-performance reports (as relating to how they score in regard to fulfilling appointments) required altering to assure pseudo-appointments do not alter their results. There were two of these to deal with.
Within SD-MobileLink, changes were needed to assure this new element of information (distinguishing between a pseudo-appointment and a real one) is appropriately uploaded to each tech.
Within SD-Mobile, it was essential that, for any
pseudo-appointment given the tech, we provide a reasonable
notification it is not a regular appointment (i.e., where he's
expected to drive to the job). On the JobsRoster page, for
example, there is this distinction:
On the JobDetails page, we figured the notice should be much
more hard-to-miss, so there we have created this extremely-visible
indication:
Similarly, much as it was important to exclude pseudo-appointments from the automated tech-drive/routing modes as offered in the ServiceDesk DispatchMap (i.e., via integrations to MapPoint or GoogleMaps), the same was important for such parallel functions as are present in the SD-Mobile. Ditto, in regarding to excluding pseudo-appointments from the semi-automated RoboCall-Next-Visit-to-Announce-Tech-is-On-His-Way feature.
Finally, in regard to SD-Mobile, there are a plethora of checks the system engages in to assure the tech has correctly prepped everything prior to submission of his PVR. Many of these are not sensibly applicable in a pseudo-appointment/pseudo-PVR situation. They needed to be appropriately excluded for that contest.
Okay, the above was not quite final. Within both ServiceDesk and SD-MobileLink, PVR-historical-text insertions had to be modified to insert differently for any PVR as submitted on a pseudo-appointment (e.g., if the tech reported that he worked on a pseudo-appointment-triggered concern from 2.35 to 2.58, you wouldn't want a resultant historical entry to read "PD there 13 THU, 14:35 to 14:58;" instead, an entry in this context has been programmed to insert in the form "PD invlvd 13 THU, 14:35 to 14:58").
As many connected operations as we have thought to appropriately modify, it's possible we missed one or more, that we should have thought of. It's also perhaps more than likely (for a set of modifications covering so great a scope) that one or more have been imperfect. Regardless, please let us know if you see something we missed or did wrong.
As a final matter of concern (and this falls entirely on you), it's very important to assure you and your techs are updated to our concurrent releases of SD-MobileLink and SD-Mobile (both must be Vers. 1.4.115 or above) before you create any of these new pseudo-appointments. Earlier versions will not know to treat them differently. In other words, if you create one of these new animals and concurrent updates are not done on the Mobile side, any pseudo-appointment will look to the tech like a real one. Thus, he's likely to go to the customer's home, but with no real appointment. Please don't let his happen. Assure your Mobile-system apps are fully updated before creating any of these new animals!
In concluding this entry, we realize you may desire an easy, shorthand method to distinguish between real/normal appointments, our new pseudo-appointments, and the old variant/option of naked-appointments. Try this:
(a) A naked-appointment is sans any JobRecord (but may expect the tech's presence at a particular place and time);
(b) A pseudo-appointment is sans any real visit (but is JobRecord attached);
(c) A true/normal appointment
includes both.
Option to Include Consumer's Email Address in Claims:
Recently, ServiceBench provided a new claim-upload format that accommodates several new fields (see notes accompanying Rel. 4.6.15). Among these is one for the consumer's email address. In conjunction with this, SD's on-screen NARDA was re-configured with a number of new boxes, to accommodate the new fields, including one for the consumer email address. Claim-upload mechanisms were similarly changed so that, if you have text in that new email box, it is appropriately uploaded to ServiceBench as an inclusion within your claim.
But there is something we did not do.
Specifically, we did not make it so the consumer's email address would automatically pull from the underlying JobRecord, and auto-fill for you to this new box in the on-screen NARDA.
The reason we did not is we'd prior heard from some servicers that they were reluctant to share email addresses, as collected by them, with manufacturers.
Recently we had a request from some other servicers to accommodate this auto-filling (one or more manufacturers, evidently, were pressuring them to provide such data). So, to accommodate both those who wish to provide the information -- and simultaneously those who do not -- we have now made the email-to-NARDA auto-fill function available, but optional.
In fact, we've done a little better than making it a mere blanket option. You can pick the particular underlying clients for whom you want the auto-fill, and have it for them, but not for others.
The option is via a new checkbox in the QuickEntryTemplate as applicable to each QET client:
Very simply, the email-address-auto-fill will occur for those clients where you've checked this box, and will not for those where you have not checked it. It defaults to un-checked, so be to sure to go in and check it (for the underlying manufacturer for whom needed) if you desire the auto-fill.
AttnNotes Now Included in Emailed Job Summary:
When you're in the DispatchMap and you click on a tech's name at the job of his list of jobs, you get a plethora of choices, regarding actions you might wish to perform in regard to that list. Among those options is to send a summary of all the jobs via email:
Until now, that particular production did not include
AttnNotes (aka "SkickyNotes") from the underlying JobRecords. Now it does.
QuickLink to the my.rossware.net Dispostion-on-Robo-Calling Report:
Are you using the CyberOffice-based features to confirm your next days' appointments? If not, did you know, with a very quick action each afternoon, you can have ServiceDesk send emails or automated telephone calls (aka "robo-calls") to each of your tomorrow's appointments, reminding them of the appointment, providing the time-frame, and requesting confirmation? Yes you can, and it's very cool.
Whether you use the email or robo-call method (you may in fact choose to use either, both or a combination), upon the customer confirming, cancelling or re-scheduling, the result is automatically placed back into ServiceDesk for you, along with a nice notation in the JobRecord's historical narrative. In the case of robo-calling, though, there are circumstances where nothing may come back. In particular, the customer may not answer their phone, in which case you may be curious to verify what happened on the robo-call (how many times it tried, when it tried, if it left a voice message, etc.). That's what this new feature is for.
Wherever in a JobRecord's narrative history you see the expression "robo-call," you may double-click on the expression, and ServiceDesk will take you to the specifically-applicable report on (as otherwise available by logging in to) the my.rossware.net website. In other words, that expression within a JobRecord's history text is, in effect, a hyperlink to said report.
Thus, you may double-click on what's shown as highlighted here:
To get instantly to an online report that looks something like this (the true telephone number below is blanked, because the image is from a real report):
If you forget this QuickLink trick, we've also inserted a ToolTip reminder to help. Whenever ServiceDesk sees that that magic expression ("robo-call") exists in a JobRecord's narrative history, it will display a ToolTip as follows when you float your mousepointer over the JobHistory box:
If you are interested in this feature and have not
setup with it, please call, and we'll work to get you going.
New "Funds Collected" Report:
Some two-and-a-half years ago (see entry accompanying Rel. 4.4.7) we introduced a new report, designed to itemize (categorized by collection source) each item of money as ostensibly collected, throughout your system, for any given date or date range. This was to provide a direct means by which to easily reconcile the money that's actually turned in by each source, for such period, with what easily reconcile the money that's actually turned in by each source, for such period, with what should have been turned in. It's been a popular report, but recently we were asked for something different.
For context of consideration here, we have always had a method whereby ServiceDesk is primed to give you notice if any item of money -- as supposedly collected -- does not ultimately show up for processing. The original (and still in-place) method is rather on the back-end. It assumes you've used some means of direct-checking as tickets are turned in, to assure appropriate matching monies are there (such as, for example, that new report we added two-and-a-half years ago). It then watches after the fact. Essentially, PVRs (and similar processes) create entries in the FundsJournal regarding each money item supposedly received. When deposited (or similarly processed), these items are "checked off." If any items persist without being checked off, they bring visible notice to themselves, by virtue of their growing and obvious datedness. If still not checked off, they ultimately trigger a direct complaint, that positively forces notice. This is our back-end assurance. Your own vigilance is the front-end.
In a nutshell, our two-and-a-half-year-ago-added report provides a very nicely augmented means to assist you in exercising due diligence at the front end. Essentially, it gives you a front-end check-off list. On a daily basis, you can print the report, and easily verify that each item of indicated money indeed shows up.
Our new report gives you a middle check. Suppose an item gets by you at the just-described front end. Maybe you did the front-end check, noticed an item missing, intended to follow up, but then got distracted by other matters, and forgot. Or, perhaps you have techs that turn in monies at such disparate times as to make that front-end check (at least via a single report) not very practical. Suppose any of the above, and you don't want to wait for our traditional back-end method to give you notice of items that did not show up. Again, we're talking a middle check.
Our new report is designed, simply, to list money items not yet checked-off as deposited. More specifically, lists them with the same "source""categorizations as the traditional front-end report (i.e., a section for each tech, one for POS, one for monies received in payment on A/as the traditional front-end report (i.e., a section for each tech, one for POS, one for monies received in payment on A/Rs, etc.). The obvious underlying logic is that if an item has not been checked-off as deposited, there is not yet verification (via such means) you have indeed collected if from the source involved.
Navigation to this new report is simple. Our report from two-and-a-years ago has been accessed, directly, via this item in the FundsControl (F9) form:
Now, if you pick that same option, you get a choice between that longstanding (front-level) report and the new (middle-level) one as now offered:
The second of the above-highlighted choices will give you the new report.
New "Itemize Vendor Invoice" Report:
This report involves an addition to the InventoryControl (F10) form. Before discussing the report itself, we'll first disclose we did at little rearranging in this form's main functions menu. Here is a comparison:
Old | New |
|
|
As you can see, aside from the fact a new item is added (the real subject of this entry), there is also some re-sequencing of items. On adding that new item, we realized the prior sequencing of functions had been less logical than it should have been. So, we worked on that logic, and added a little line divider to separate functions into two logical groups.
Now for our real topic. Do you see which item, above, is the new one? Here is some help:
This report was long requested by Bob at GRA-NEVA
Appliance Service. He calls it a "Receiving Report." The
idea is to provide an easy means to see precisely what was ostensibly
received on a given invoice from a given vendor. It allows an easy
means to verify what was entered as received corresponds with what
the vendor has on his invoice. When you run the report, it will
initially display on-screen. However, the form's PrintList button
will appear, and you can just click on it if wanting to print.
Dramatically-Enhanced Spiffs System:
Earlier this year (see entry accompanying Rel. 4.6.8) we offered a very simple (e.g., lightweight, minimal) system to accommodate a program of special, motivational payments you might wish to setup for your employees. It was, indeed, minimal. With this release, we offer a much-expanded (and considerably more integrated) spiffs system.
In fact, the design of this system is such that it might (according to your preference) constitute an entire compensation system for your techs, and according to your own design (i.e., in lieu of hourly, salary or commission basis).
There is a new mini-manual fully describing this new system. For the new mini-manual you may either click here, or, if you go within ServiceDesk to its Rate of Earnings form (Alt-F2), there is a new button there to provide a link:
Integrated Facilitation for Direct-Ship-to-Customer Part Orders:
Have you heard of doing this?
Instead of having special-order parts shipped to your own office location (where you must unpack, inspect, temporarily store -- and, finally, arrange for transfer to the tech prior to his returning to the home for a scheduled visit -- you instead have them shipped direct to the customer.
In this mode, there's no need to for you to unpack, inspect, store or transfer to the tech. You just schedule for the tech to go out, and send him. He finds the parts waiting for him on his arrival. Among other advantages, if the part is of the kind where cosmetic blemishes can lead to rejection by the customer (e.g., a refrigerator door panel), you can ask the customer to open and inspect prior to even booking the return appointment. This can save many wasted trips.
You may be skeptical of this method (and, sure, there a few drawbacks), but the advantages are legion. Those intrepid businesses that have switched to the method vehemently swear by it. They say they'd never go back, in a million years.
Enter our new feature.
If you're using the direct-ship method, there's a considerable amount of added info to give your vendor, in connection with each ordered item (or set of items as applicable to a particular job). Specifically, you must provide the customer's full shipping data. It's at least three lines of text, and takes considerable time to manually provide in each instance.
That's why we've added a new method in the F8 form's Assemble-Order interface. This is where you select the display category titled "Items needing ordered." You then do a series of Ctrl/Right-Clicks on the items you wish to include in the particular request you are formulating (i.e., "marking" them for inclusion), then hit Enter on your keyboard. At this point you're presented with a dialog that asks you to pick the particular method, as wanted, for conveying the order to your vendor. Here's a comparison of that dialog box, from old (prior to this release) to new:
Old dialog, as shown in F8 after you've selected items for inclusion in an order, then hit Enter | Image of the new dialog, with newly-added option circled |
|
|
As you can see, the new option involves emailing your order, with inclusion of "ShipDirectToCustomer Instructions."
Here is what the long-offered (and standard) Abbreviated-format request looks like:
As compared to the new, ShipDirectToCustomer-oriented request:
Logically, the system looks for appropriate ship-to information in each request-item's attached JobRecord. Exercising further logic, if it's a JobRecord that lacks a consumer's addresses (particularly as in a POS situation that was not setup for direct-shipping to the customer), or one that's designated as a ShopJob, the system will automatically alter the request to specify shipment to your office, as opposed to the consumer.
New "Resurrection" Option in archived-PartsProcess:
Back in June (see entry accompanying Rel. 4.6.16) we introduced a "HpToRtrn" status category for PartsProcess items. This was to accommodate the situation where you have a maximum return quota with a particular vendor, and present return of the item in question would exceed that quota. Thus, you place it into this status to designate you'll want to return if sufficient future vacancies allow, or (even better) you'd love to use it in the meantime on a different job, should the opportunity arise.
There's one element we did not work out in that scheme. It is this. Suppose some other job comes along on which you can use the item in question. How do you transfer it from the job on which it was originally ordered (and not used) to the one you wish to use it on now. We simply did not go so far, last June, as to work through this conundrum.
Of course, our users are ever-practical, and Mitch at Video Tech Center invented an answer. His solution was to employ a method we created in December 2010 for a somewhat different purpose: the "Resurrect" facility (see entry accompanying Rel. 4.4.89). The general idea, in a "resurrection," is an archived-PartsProcess item can be restored back into the current context. As originally conceived, this resurrection option was provided solely for the situation where you allowed a Process item to go to archive before realizing you needed to attach a daughter-band for the purpose of managing a core return. Resurrection allows you to restore it back to current for that purpose.
In a nutshell, Mitch realized he could use resurrection for a different purpose. However, he also discovered the existing structure (as tailored for its original purpose) was not optimum to his invention. So, we've made a variation that is:
Old dialog, as shown in Crtrl-F8 when you right-click on a process-item | New dialog, with newly-added function circled |
|
|
As you can see, the new dialog adds a new/second resurrection option. If you pick that option, you'll further get this dialog:
Obviously, if you want to move the item's application to a different job (i.e., different from the one it was formerly ordered-in for), this dialog provides the basis.
This new method provides appropriate documentation at all points. The moved-to JobRecord will have an appropriate notation in its narrative history, so on, and etc.
Other PartsProcess Improvements:
There are too many of these to list individually, but simultaneous with the current new features we fixed an entire series of moderate defects that had been noted, particularly as regards our cradle-to-grave structure.
QuickLink to RepairClinic.com:
RepairClinic.com (http://repairclinic.com) has become a useful website for many businesses. Some of you are going there with great frequency, especially to lookup parts as applicable to a particular model. To make this easier, we've added a new QuickLink. In the F8 form, just do a Ctrl/Right-Click on any model number (specifically, as present within a process-item's Model-Number field). In response to this simple action, ServiceDesk will open a RepairClinic.com website page for you, with a completed search on the model in question.
If you forget the command, it's also been added to the contextual CheatSheet (just right-click in the colorful label-area at top of the F8 form), as follows:
We have also, incidentally, added the same function
into SD-Mobile.
Protection Against Unintended "Within-90-Days Repeat" Claims:
The request for this came from Ken at Shaughnessy Appliance (in Alberta, Canada), and in retrospect I realize it's a feature that should have been there long ago. Quite simply, when you go to submit a claim from ServiceDesk's Alt-F4 FinishedForms context, the system will automatically do a behind-the-scenes check, to see if any other relevant claims were prior submitted within 90 days preceding. Any such prior claim could potentially be on the same job, or on a different job but involving the same underlying unit. Depending on which is the case, if applicable, you'll get a message such as this:
Or this:
All you need for this new benefit is to do the update.
Improved Formatting for Lowes Claims:
From time-to-time we learn on the basis of feedback that particular elements of claim-formatting must be done in uniquely different ways, for particular underlying claimed-upon payers. As we make these discoveries, we adjust our claim-formatting mechanisms to appropriately adapt. Recently we learned of a whole slew of departure-from-the-normal-rule elements that needed to be applied when claims are submitted to ServiceBench, and with Lowes as the claimed-upon party. Absent these unique applications, it turns out, claims as uploaded under Lowes accounts have required online fixing of particular element before they are accepted. Such online fixing is not something we want you to have to do.
This release incorporates all the unique-to-Lowes modifications, which we have just learned are in fact necessary. If you have prior found that all of your Lowes claims required after-the-upload-online-fixing, you should now be pleasantly surprised to find this is no longer the case.
Enhanced/Built-in Re-sorting of Certain DataFiles, Plus Reporting-Checks:
One of the most immutable rules of programming is borrowed from larger life: it's that infamous "Law of Unintended Consequences."
Bowing to demand, we have in the last couple of years made it increasingly easy (in the latest addition of ability, see notes below accompanying Rel. 4.5.60, it's virtually automatic), to make entries to the SalesJournal on the basis of putative entry dates that are other than the true current date. It turns out that out-of-date-sequence entries can cause issues for certain reports and processes that expect to sort through a file rapidly to find entries fitting a range of dates.
Based on such issues, a significant while back we added mechanisms that automatically re-sort the SalesJournal with each nightly housekeeping event. But it turns out other files are affected too, including (most particularly) the FundsJournal. We have also found that sometimes folks simply backdate a computer, and by such means manage to input entries that mess up the normally-expected sequence of dates.
To address such issues, this release adds further built-in, automated nightly sorting for the FundsJournal and InventoryMovementsJournal.
Additionally, since there are number reports within the F11 Reports form that rely on the SalesJournal being appropriately sorted, this release also adds a behind-the-scenes checking mechanism, designed to assure it's not out-of-sequence whenever you go to run a report there.
New Printing Option from FinishedForms:
This picture likely says it all:
Sometimes folks use the FinishedForms to make a
nice printed invoice for property managers, and similar. We
learned sometimes when the bill is big and the paying company sees the
tech was only there for a short while, it causes problems. This
option gives you the opportunity to refrain from showing the time or
times your tech was on premises at the job.
New Warranty-Claim Format -- for Warrantech:
When you're in the Alt-F4 FinishedForms interface and to go to transmit a claim, there has long been a significant list of entities for whom the claim can be formatted. The final option has long read "Others . . ." It has further long been the case that when you click on "Others," you get a little message that essentially says: "If you need to submit claims in any format other than as listed here, let us know, and we'll add that format to the list."
That just happened in regard to Warrantech, a company that markets and services extended product warranties. An option to format claims in their format has now been added:
If you need assistance understanding which boxes from the onscreen Narda fill to which Warrantech fields, please use the Translation Tips, just as for any other format. Please also be aware there is no direct-transmit method for Warrantech claims. Just as with Dacor, Fisher Paykel and Samsung, you'll be saving claim info into a file, and it will then be up to you to assure that file is appropriately uploaded to Warrantech.
Additionally, please note we are not confident these
claims will work perfectly, right out of the box. Warrantech's
documentation (regarding the expected claims format), leaves significant
ambiguity. From such documents we have made our best
interpretation of what they are seeking, but your experience may prove
our interpretation was off. If so, we will need (and look forward
to) feedback to correct.
New Feature to Cope with Teeny Return Quotas on Parts:
Recently we heard from a user that Samsung has imposed a limit on the quantity of parts that can be returned, within any given month, and return credit received. The limit, we understand, is 5% of whatever is the total purchased.
OUCH!!!!!!
This means if you've done $10K in purchases in a given month, your returns cannot exceed $500. It's a pretty tiny limit, and means you could potentially be stuck with some losses, if ServiceDesk did not do its best to help you (even then you might, but at the least ServiceDesk should do all that it can).
That's what this release is about.
We have added a new HoldLoc category in the PartsProcess system, as follows:
The idea is, if you need to return an item and either lack quota space for the return within the current month or you want to delay until deciding how to juggle items within your max quota, place the PartsProcess item into this new category. It can then be reviewed and managed, under that particular and new category, via the various "To-The-Grave" management functions, just as is applicable with other categories.
In this case, there is an added and further special function. You are likely familiar with the fact that when a user is working to special-order a part (and when the same part number happens to exist in inventory), the system attempts to interdict the order. Basically, it injects a message informing your user that the part is in inventory, and it would make far greater sense to use the instance that's in inventory, as opposed to special-ordering the item.
So, here's the further logic. If you can be assisted in using a part that you'd been hoping to return (by having notice provided when a user is about to re-order the same item), it not only means more quickly satisfying what had been perceived as an order need; much more powerfully, it means there's no longer a need to fit that return within your very skinny return allowance (thereby making potential space for other returns within said allowance).
So, what we've done is added to the same behind-the-scenes call that looks within your inventory to see if an about-to-be-processed special-order request can be satisfied from inventory. That same call now makes a further check, to see if there are any special-order items in the Special-Order system in this new status, and from which the request can be satisfied. If so, it presents a message similar to the following:
Nothing is needed for implementation of this new
feature, save using the new category. There is, however, one
caveat. The system creates its behind-the-scenes ready-access list
(that is consulted for this check) each night as part of the
Auto-Archive process. This means that if in a current day you have
just added an item into this new category, it is not available
for producing any of these new alerts until the following day.
New/Advanced Format for ServiceBench Claims:
Recently ServiceBench introduced some new claim fields, that allow us to now provide more information as connected with each claim. This release of ServiceDesk will upload in the new format, and is needed for all ServiceBench claims henceforth, as it's this new format their system is now expecting.
Among the new fields that will now be uploaded is a "Date Started" field. This is different (and to be distinguished) from the long-standing "Date Call Taken" (aka OriginDate) field. Its purpose, in part, is to allow improved metrics on service company performance. For a long time, servicers complained that in many instances longer cycle times were induced by the fact a consumer requested a first appointment that was many days (sometimes weeks) out. Where the only measurement of cycle time was a comparison between OrginDate and CompletionDate, this kind of situation was indeed sinister. The new field is intended as an indication of when the tech first walked into the customer's home, to begin work. A comparison between that date and CompletionDate can be significantly more meaningful.
Within SD's on-screen NARDA, we've jostled the boxes a bit to accommodate some of the new stuff. Here is one comparison:
Old section area | New section area |
|
|
If you look carefully you'll see there is also a new CustomersEmail box. We have not currently coded for this box to auto-fill with importation of a job to the NARDA, as it's our estimation servicers may typically not wish to share email addresses (such as they may have collected) with underlying ServiceBench clients. If you fill-in the box with an email address, it will nevertheless transfer to ServiceBench (in other words, for the time-being we are leaving this field for you to fill-in manually, if it's a piece of information you want to upload).
Another difference in the new format is that, where
COD jobs are involved, ServiceDesk can now (assuming such information is
provided in the NARDA) upload information concerning amounts charged and
monies collected (if you do not desire to so upload, simply leave this
info absent from within the NARDA).
Printing Option in PartsPick Form:
Slightly more than a year ago, we introduced the wonderful PartsPick form (Ctrl-Shift/F8). Its purpose is to provide a one-stop venue, to see all parts that should be getting moved to or from each truck, as relevant to the past and next day's work. Recently someone pointed out there is often a need to move away from the computer screen, to where parts are actually at, to accomplish these movements, and it would enhance ease if the information could easily printed to a piece of paper, which, in turn, a person can then use to walk about, locating each applicable item.
Ask and ye shall receive.
In it's lower-right corner, the form now has a new button:
If you want to print the list, click on the button.
It's that simple.
Better Accommodation in the Inventory System for Multiple Warehouse/StoreRooms:
Initially, SD's Inventory Control system was built with the assumption that, aside from such inventory as kept on each truck, each service operation would have a single inventory storeroom ("OF"), and movements to and from the the trucks would all be via that single location. You might call this the "assumed-office-storeroom-as-hub" premise.
In bits and pieces, we have transcended that premise.
Quite a long time ago, for example, we made it so you can specify and manage inventory locations that are independent of either techs or the assumed office storeroom. Just a couple of years ago, we made it so restock shipments can be checked directly into any location, with no need to pass through the office storeroom first.
Recently some users have wanted to further transcend the "assumed-office-storeroom-as-hub" premise. This release accomplishes such transcendence in two respects:
1. Within the F10 form's two main Transfer-Items functions (typically used to restock a tech from office inventory), you may now optionally designate a source other than "OF" as the "pull-from" location. Stated more simply, you may now move a set of designated items directly from one truck (or any other non-"OF" location) to another.
To do so, you simply must select the function in a slightly revised manner (this slight revision informs SD of your intent to specify a different-than-standard "OF" source for what's being moved)
We added the capabilities in this manner because we did not want to slow down the more typical scenario by placing an added inquiry into it. As you can see from the above, if you want the source to be other than the standard "OF," just right-click to select the function (as opposed to what would otherwise be a normal left-click) -- or, if you're using the quick-key access method, hold down Ctrl while doing so. Either method tells ServiceDesk you want to designate other than "OF" as the source, and it will provide a dialog for you to indicate such other.
2. When speculatively-tagging items from stock for particular jobs, you may now indicate a source (for such tagged items) other than "OF." Suppose, for example, you have a second physical location (with its own inventory storeroom), and sub-set of techs who work from it. If you're spec-tagging parts for jobs those particular techs will be going on, you'll want to tag them to inventory as located at that secondary location, and not at your main one.
The contextual guide to use of this feature is provided in the F7 form (i.e., same context from which you initiate a spec-tag) via a Tooltip that arises when you float your mousepointer over its "Tag Part for Visit" button.
As you can see, the method to designate other-than-standard/assumed-location parallels what we just saw above. Do a right-click (as opposed to standard left-click) on the button, or modify the quick-key shortcut with Ctrl (please note that if you happen to have your Windows focus in a text box, the "Ctrl-V" quick-key method will be superseded as a Windows Insert command).
Alternate Sales-Tax Rates for POS operations at Satellite Locations:
If you have multiple locations, each conducting POS operations, and if those locations are subject to different tax rates, this one is for you.
This is one of those solutions where the need is so rare that, rather than providing a direct user interface whereby you can specify this variation, we're asking you (should you have the need) to create a little file that will tell ServiceDesk what it needs to know for your circumstance.
Here are the brief instructions:
Open any text editor (e.g., Word, WordPad, NotePad, etc.).
Type the first rate (it's the rate on materials if you're U.S.; PST if you're Canadian), then Tab, and type in the second rate (the rate on labor if you're U.S., GST if you're Canadian). Type each rate as a decimal fraction (e.g., 7.25 percent would be typed as .0725).
Save the file as "MyPosTaxRates.TXT", and be sure to save as as "File-Type" Text-Only.
Place a copy of this file into the operative LocalData folder as applicable to each station where needed (i.e., any that needs POS tax rates other than as placed into the ServiceDesk Settings form). To determine which is the applicable LocalData folder at any station, bring up its About ServiceDesk form; a list of applicable paths is in the lower-left.
The above is all you must do. ServiceDesk looks for the above-described file on startup. If it sees it, if reads inside to find the two, special-for-local-use rates you have provided. It then applies these in the POS context, for the station involved.
Spiffs (or Alternate Use):
Occasionally, we accommodate needs, but in less than a royal fashion (our logic is that it's impossible to do everything royally, and some provision is better than none). In this case, a client finds it useful to pay techs particular add-ons, for things like selling water filters. It's practical for the operator that's making SalesJournal entries to keep an eye out for those particular items where such spiffs should apply, but less practical to make notes in each instance in any context outside of ServiceDesk. A method was desired via which said operator could denote, as connected with each such SalesEntry, when any such spiff was applicable. This release accommodates that.
Specifically, when in the SalesEnter form (F9) and making an entry, if as an operator you note it's a sale on which a spiff should apply (or any other special notice you want to attach to the sale), simply right-click in your entry line, before hitting Enter to insert it. This can be done before you've entered text, during or after. What matters is simply that it's before hitting Enter for the line's insertion.
In response to this right-click action, the system will query you for text entry (up to eight characters), which will become part of that SalesJournal entry, in a special little OtherData field. If you're using it for the Spiff purpose, perhaps you'll put in an actual amount (or perhaps a description of the Spiff: whatever purpose you wish to achieve).
This new/extra field is not generally viewable, because at this point we've not wanted to revise all the other many mechanisms with which the SalesJournal is associated (it would be a more major project than we're presently ready to undertake for this purpose).
Instead, the main place to make use of this new field is in a Sales data export, as available from the Reports form (F11), after having ran a SalesSummary report for any period of interest (look for the "Export with Extended Data" button in the form's lower-right). When you run the export, you'll find a new field in the output labeled "OtherData." This field will contain whatever you've input via the method above-described.
Of course, you may sometimes find mistakes were made, and need to be fixed. For that reason, we've also provided limited access to this field from the SalesView form (Shift-F3). Simply use the method you wish there to display the item or items of interest. If you wish to see (and perhaps revise) the "OtherData" field as attached to any item, simply right-click on it.
Again, the mechanism we've provided for this purpose
is a bit "back-door"-ish in nature, but for now (and for the
particular/atypical need involved) we hope it will be adequate.
New "Time-Allocations" Report:
Back with release of Ver. 4.4.68 (see entry here for 5/24/10) we introduced an awesome DTR-Viewer (Daily-Time-Report) , via which you may review, with super-intuitive graphics, precisely the time segments each tech spent on the clock, and -- for such segments -- which specific portions were checked-in/working at actual customer jobsites. It's a super tool, and, if you've not been making use of it, we highly encourage you to do so.
Recently, certain users desired some of the same information that is there presented graphically, but in a textual format, and instead of encompassing simply a single-day of information at a time, to encompass a user-specified span of days. So, we have a new report to accomplish this purpose.
As you might guess, this new report is accessible from the Reports form (F11). There you should select "Performance - Techs," then "Time Allocations:"
|
|
Pick your date range as prompted, and you should see something like the following in result.
Please bear in mind that, like some of our other
recently-added reports, this one too depends on the computer involved having
Excel installed, which is a component of Microsoft Office.
New "Tech-Status" Display in the DispatchMap:
For those of you using SD-Mobile (it's most of you), we've found that many have not known that to see when each of your techs last connected (and which version of SD-Mobile each is running in), you can simply click, within your in-office SD-MobileLink program, on its "Test Connection / Check Link Activity" button. This produces a quick little report, on the details just mentioned.
Of course, the above-described program is only accessible from a single desk (the one which runs the MobileLink program), and we've learned folks at multiple desks would in some instances like to stay informed, throughout each day, as to the status of each tech in terms of informationally connecting with the system. So, we added a new display:
Besides needing this new version of ServiceDesk to deploy, this new feature also requires an update in the MobileLink program to its (currently offered) 1.4.97 or above Version (absent that update the enhanced display in ServiceDesk will show nothing but blanks for the indicated times).
Non-Job "Naked"-Appointments will Now Port to the Tech in Mobile:
In the ServiceDesk ScheduleList form (F6), there has always been the ability to click on the "New" button, and create a straight appointment entry that is not tied to a job. These can be used to put "Vacation" entries into the schedule, for example. Or, to put into the schedule an office meeting that you expect particular techs to attend. Or, to schedule a time for a tech to have his truck serviced, etc. The possibilities are almost endless, and we've determined to call these "naked" appointments because, well, they're not tied to a job. These appointments show up (just as do job-tied appointments) within the DispatchMap, providing a nice, on it's face indication of how each applicable tech will be occupied during the times in question.
When we created the mechanisms in SD-Mobile that pull appointments from ServiceDesk, our thinking was entirely tied to the standard, job-connected appointment scenario, and we neglected to accommodate this other kind. Thus, until now, SD-Mobile has not been displaying these "naked" appointments for the tech.
We realized this oversight early-on, but have been slow to address it because there was an easy, user-based solution. Many companies created one or more fake "jobs," to stand-in for such things as office-meetings, and made appointments for those fake jobs as needed (thus, these show up for the tech in his Mobile interface just fine). Though the expedient has served well, it's nevertheless been a little less than elegant.
The current releases of SD-Mobile and SD-MobileLink (updates in both are needed) address our original oversight. Now, "naked" appointments as made in ServiceDesk will port directly to the tech in Mobile. There is no longer any need to maintain fake jobs, within ServiceDesk, to "clothe" them.
You may note that, directly speaking, it's an improvement in Mobile mechanisms we're announcing here, and, normally, Mobile-side improvements are announced in the SDM-WorkDiary (as opposed to this, the SD-WorkDiary). However, it's within ServiceDesk where you need to know about this improvement, in order to take advantage of it.
Updated SD-Backup Program:
Since long before it was first introduced to the public, ServiceDesk has had a companion program called SD-Backup. It's designed to run in the background from any non-server station in the network, and automatically makes regular backups of ServiceDesk's primary operating data. We highly recommend you have this program rigged to run automatically, at least every day throughout the day, if not (indeed) 24/7.
Having been developed so early, this program had grown
somewhat archaic in comparison to the SD system whose job it's been to
backup. Josh, here, undertook the task to fully update and modernize
this little program. While he's been doing a ton of very sophisticated
web-side programming for us, it's his first foray into programming directly
for the desktop on behalf of Rossware. I think he's done a fine job.
Please update to this latest copy of SD-backup. Unlike ServiceDesk,
the update is not automated. You'll need to go to the ServiceDesk
downloads page, pick the update there, and be sure to unzip to the correct
folder (where you otherwise have ServiceDesk itself installed and running).
This means you may need to change from the default "Unzip-To" path.
Also, please be sure you don't have the old SD-Backup running when you
unzip. If you do, Windows won't allow the old program file (in-use for
the running program) to be replaced.
Beefed Up "Result on Dispatches" Report:
Four months ago we introduced a new report (see notes accompanying Rel. 4.5.67). Many call it the "FCC" (First Call Completions) report. For all appointments as dispatched during a period, it shows whether the job was: (a) completed; (b) parts were ordered; (c) it was a customer no-show; or (d) there was some other disposition. It breaks down such values by tech, and shows totals for the team as a whole. It further segregates between appointments that involved a first visit, versus appointments that did not, and provides aggregates for all appointments as a whole.
This release enlarges on the above.
Specifically, besides providing breakdowns on these figures by technician, it segregates between in-warranty and out-of-warranty. It segregates between OEM-warranty High-Volume-Clients and non-OEM-warranty High-Volume-Clients. It segregates between any-and-all third-party-bill jobs, versus non-bill jobs. Then, it provides breakdown figures by each and every particular HVC, then by Make, and finally by Type of machine being serviced.
If all the above segregations are not sufficient to your
analytical desire, the accompanying Check-Data export provides all the
specific data as needed, should you wish to do any further segregations (or
cross-segregations) on your own.
New Sales-Tax Strategies Now Available:
If you're observant, you'll note this release involves a Version-level change (from the 4.5 to 4.6 level series). We do these Version-level changes as infrequently as we can. They are necessitated wherever, to achieve some new function that is considered essential, we must re-format one or more existing data structures. In this case, re-formatted structures involve two areas: the SalesJournal and A/R files. Upon first running under this new Version, ServiceDesk will automatically read data from your old such files, and create a new files in the now-current/new format. To assure preservation of data integrity, users will be disabled from further using 4.5 series of ServiceDesk, once any station has run with this new version
There are two elements in particular we've made possible with this change.
First, you may implement an entirely new strategy for managing sales-tax rates and applicable jurisdictions. In particular, you can define a set of taxation schemes, and assign each/any job to the scheme to which it (in your judgment) belongs.
Second, you may explicitly keep separate track of the two tax constituents as involved in each sale (particularly important for a small group of Canadian users with separated PST and GST).
Given that ServiceDesk now has several tax strategies that may be implemented, we decided it was time to create a Tax-Strategies Handbook -- to provide a one-stop, comprehensive overview and guide. It's there you can learn details, both about what's newly offered in this release, and to guide your implementation of tax strategies in general.
It's obvious you can click on the above link to open this new Handbook. Additionally (and for convenience when not looking at this particular entry), it may be accessed any time by going to the ServiceDesk Settings form (Ctrl-F1), and there clicking on the little "?" button that fits between the two tax-rate boxes:
This new Handbook is designed to supersede what had been a
more limited document, which explained simply how to setup a TaxRates file
(which file involves just one of several potential strategies, as now outlined
in our presently more comprehensive Handbook). There are elements in this
new Handbook that likely everyone could benefit from reading. We recommend
that you do.
Tagged-Parts Disposition Added to In-Office Type-2 PVR:
This is another instance where the in-office Type-2 PVR (which long pre-dates the newer PVR as present within SD-Mobile) has been after-the-fact brought up to more advanced standards as created within the newer/Mobile system.
Specifically, quite early-on the Mobile PVR interface was engineered to show a tech items that had been spec-tagged for the job, and demand he indicate whether he used them or not. If not, it demands that he indicate why not (just as the same as for special-order parts).
With this release, the in-office Type-2 PVR adds spec-tagged parts to the same listbox where it's prior requested a disposition check-in on special-order parts. Thus, there is no need to enter usage of such items in the "Items used from Inventory" box. It should be done from the specific dispositions (PickList) box instead.
BTW (and so y'all understand for context), the Mobile mechanisms are and will remain where our first focus goes when it comes to interacting-with-the-tech's-work features. Regardless, there are still a number of users who've not gone to Mobile, and in a reasonable degree we want to keep the in-office alternatives up to snuff.
Improved Days-In-Past Appointment Viewing in Dispatch Map:
SD's DispatchMap (F5) is obviously used most frequently for
viewing and managing your roster of appointments as applicable to the present
day and days that still lie in the future (tomorrow, the next, etc.).
However, it is also sometimes used to view days in the past. It has
sometimes been somewhat inconsistent in this task. The programmed
algorithms as used to locate the appointments as applicable to a given day
sometimes have worked imperfectly, resulting in less than perfect results.
In this release those algorithms have been totally re-worked, and should prove
to be much more reliably robust.
Automated "Call-to-Next-Customer" Function Now Added in SD-CyberOffice/SD-Mobile:
Technically, this is a CyberOffice feature -- but, as with a few other CyberOffice features, its implementation is only practical within the context of using SD-Mobile.
What is the feature?
Quite simply, as the tech indicates he's completed one job, an automated telephone call can immediately go out to the next stop, informing their tech is on his way. This is a further implementation of the "robo-calling" function we added a few weeks back (see entry here accompanying Rel 4.5.58) for use when confirming/reminding on appointments (as typically done the day prior to the actual appointment date).
To use this new implementation, you need to be subscribed to both SD-CyberOffice and SD-Mobile (if you are not, call, and we'll get you setup). In the CyberLink program (you'll need Ver. 4.5.12 or later), you'll need to "check" a new box to "turn-on" the feature:
Once that is checked (and assuming your technicians are updated to SD-Mobile Ver. 1.4.86 or later), they'll see a new popup appear whenever they click, in the Mobile interface, on a job's "I've Finished" button (at least assuming there are more jobs following the one involved):
As you can see, it's very fast and easy for the tech. Within seconds of his consent, a telephone call will go to that next stop. When the call is answered, an electronic voice will identify the call as being from your company, and inform of the tech's soon-to-be-expected arrival. Specifically, if your tech has picked the first-provided option, it will (after identifying your company) state: "Your technician, [insert technician's name], is just finishing his prior job, and then will be on his way. Please have your machine accessible and ready to be serviced. We will see you soon." If he picks the second option, it will speak similarly, but state the number of minutes within which the tech is expected to arrive.
Very simple, we think, and very effective.
Improved Setup for BarCode Inclusion (or not) in PartsLabels:
We added the option to include barcodes within PartsLabels over three years ago. On recent review, it was realized the method as then created to allow the user to specify whether with-BarCode labels were preferred (as opposed to standard, text-only labels) was less than optimum. With this release that awkwardness is corrected. There is a new Settings option in the PartsProcess form's CheatSheet (from the F8 form, click in any otherwise non-operative space):
Just click on this CheatSheet item, and you can then pick yea or nea for use of BarCodes (the default is nea). (Incidental to adding this new Settings option, we realized the dialog on the three items above it were not as optimum as they could be; so those have each been independently improved).
"Check-Data" Export Added to the new Result-on-Dispatches Report:
About a month ago (see entry accompanying Rel. 4.5.67) we introduced a new report designed to specifically show percentages and quantities of dispatches that ended in completes, ordering parts, no-shows and other, broken down by techs and other criteria. When creating that new report, we suspected there would be desire for a corresponding option we've prior provided in connection with several reports.
What happens is sometimes folks run these reports and do not feel the results are credible. Our solution is to provide what we call a "Check-Data" export. The idea is, as the code churns through your data to produce the final tallied figures, it simultaneously compiles an item-by-item table that contains the specific data it relied on for the tally. This allows you, if you feel in way any skeptical about the tallied result, to open that table (exported data) and review the items one-by-one, to see if there is any discrepancy in how the reporting mechanism handled and judged your data.
Other reports, that already had this "Check-Data" function, were the TechsTimeOnJob report, TechsCompletionAnalysis report, TechsRevenue report, both Recall-Rate reports, the QualityOfService report, MarginAnalysis report, Profitability report and PayForPerformance report. The simple idea is, after the report displays, there's an added button toward the lower-right corner of the Reports form:
If you want to review the "Check-Data" export as applicable to the report, just click on that button.
Anyhow, that's all background for stating that, sure enough,
some folks soon requested that our new "Result-on-Dispatches" report be
equipped, same as these others, with its own "Check-Data" export. That is
now added, with this release.
New SmartsParts Data Release, and Enhanced/Canadian Pricing Option:
Typically we have been updating SmartParts data about three times per year, and our last update was in November, which made us not quite due presently (typical pattern-wise, that is) for another update. However, we were informed by a few users of SmartParts pricing (in particular on Whirlpool products) that was significantly too low. On investigation, we learned Whirlpool had released new pricing, with very large increases on some items, not long after our prior update. Thus, it made sense to do an update of our own immediately, rather than waiting for the normal update cycle as is more typical.
This update also applies, incidentally, to the SmartParts data set that's automatically built-into (and included with) the SD-Mobile service. It's virtually automatic there.
If you're using SmartParts otherwise (i.e., in the office), please do a SmartParts data update immediately (go to Alt-F10 and click on the CD-tool symbol in toolbar at top).
If you're not using SmartParts otherwise, we highly recommend you install the data (call us for user/download credentials) and check it out. Most who've gotten used to it consider it indispensable. You may try for 30 days for free.
If you did not know, SmartParts is both a data set (models and serials, with lookup on models of fast-moving parts), and is also an independent, run-on-its own program. The Alt-F10 window within ServiceDesk is essentially the same interface as is presented by the stand-alone SmartParts program. If you're using ServiceDesk, there's little need for the stand-alone program, since you get virtually the same interface within ServiceDesk (the stand-alone program was mainly intended for non-ServiceDesk users, though you're welcome to use it in such form regardless, if wanted).
Anyhow, there is an element functionality that until this release of ServiceDesk could only be accessed from within the stand-alone version of SmartParts. It's a feature that allows you to specify for download, into the SmartParts data set, parts pricing that's particular to a participating parts distributor. To date, the only distributor who's setup to provide such pricing is Reliable Appliance Parts, and theirs has been available for several years. More specifically, their U.S. pricing has been available for several years.
In such regard, a recently-implementing Canadian user, noting that Canadian prices are not the same as U.S. prices, asked if we could get Reliable (which is very big in Canada) to provide the same data as they've already been providing, but with Canadian pricing instead. They agreed, so now (within the SmartParts) interface, you can specify to grab particular-to-distributor pricing from either Reliable-US, or Reliable-Canada.
Additionally, while the dropdown for this specification formerly existed solely within the stand-alone version of SmartParts, it's now available from the within-SD interface as well. From the ServiceDesk Alt-F10 view, just click on the "i" information symbol on the toolbar.
The option you select has effect when you click on the
toolbar's CD symbol to update.
Added Security Tracking:
We've long had some pretty elaborate security built into ServiceDesk, including elements that log (in various contexts) a whole series of user actions. Recently, though, a new user had an idea for a kind of logging we were not doing, and it seemed like a great idea.
In a nutshell, any time a user is asked for and presents a password, our new log will record that specific event, as such an event. The logfile that's built is called KeyIncidents.csv (the word "key" is employed because passwords are essentially particular keys inserted into the locks of particular doors), and will open nicely in Excel:
As you can see, the first column indicates when the event occurred. The second identifies the security context involved (you can reference your ServiceDesk SecurityActions form, Shift-F11, for meaning). The third identifies a string as associated with the particular key/password as used (aside from MasterPassword, this comes from the second column on the Users page within the SecurityActions form). The fourth identifies an abbreviation for the username under which the applicable instance of ServiceDesk was operating. The fifth identifies the name of the computer the program was running in. The sixth is a data integrity number. Basically, it encodes certain parameters for the file and entry that will permit you, if the need should ever arise, to determine whether the file has been subject to edits.
In regard to this last, we could have configured the file to be encrypted, but that opens up its own complications, We deemed the tamper-evidence numbering system as a more simple expedient, better tailored to actual level of security need involved.
With this particular release, the file will be found within
your system's operative \sd\netdata folder. From the next release forward,
it will found in the \sd\LogFiles folder.
Core Return Labels:
As we add new features, it's almost inevitable that one thing leads to another.
Back in August of 2010 (see notes accompanying Rel. 4.4.73) we added direct Core Return functionality where, essentially, a PartsProcess daughter band is created (and connected with the parent band on which the replacement itself was ordered) to manage retrieval and return of the core. Of course, we'd long had the ability to create parts-labels from these bands, but it had not occurred to us to alter for different/special label printing as connected with a core-return daughter band. A new user suggested it, and it seemed like a good idea. So now, if you choose to create a label from such a daughter band, instead of a standard label you'll get this:
You'll note it's just a big, maximum attention-grabbing label,
without details specific to the item involved. We figure the main label
that you print (from the next PartsProcess item above the core-return listing)
will have the details, and the space within the next label should be used for
maximum attention. We also realize you could advance-print many sheets of
labels with such simple printing, but the in-process context as here provided
should make the sequence far more convenient.
Tax Liability Report Very Much Improved In Appearance:
Almost a year ago (see entry accompanying Rel. 4.5.3), we introduced a compiled Tax Liability Report. We emphasize the word "compiled" to distinguish from the pre-existing situation. The concern is for users that must report on tax liabilities to different jurisdictions and at different rates. We'd long provided exported data via which these separate obligations can be deduced and reported, but did not prior do the actual compiling of summaries for you. That's what our new report (almost a year ago) introduced. However, it was not a good looking report. It placed plain text into a simple Excel spreadsheet that otherwise lacked any formatting to enhance clarity and easy understandability. That's what is now improved. The Excel spreadsheet as produced by this report now looks like this:
(The old one looked so bad we're embarrassed to show it even for contrast.)
You'll notice the little red comment flags next to each jurisdiction title. When you open the comments provided, you'll see they provide a listing of the zipcodes that, for the sales reported on, were found to exist within each such jurisdiction. Other appropriate contextual notes are also provided, for the sake of any assistance you may need in interpreting the report.
Tax Jurisdictions May Now be Defined at the Sub-Zip Level:
The above-described presentational improvement was triggered when we were working on a more substantive improvement, as we'll now describe.
Almost three years ago we introduced the ability in ServiceDesk (again, we're dealing with users that have different tax rates in different jurisdictions) for you to define the rate as applicable within each jurisdiction via creation of what we call a Tax-Rates file (see entry accompanying Rel. 4.4.5). The simple concept is you list each zipcode, and for each indicate the jurisdiction that's applicable, and tax rates. ServiceDesk (and SD-Mobile) consult this file when needing to ascertain which rates should be applied to a job within each such zip area. So does the above-described report.
It seemed like a great plan, but with one caveat. We soon received reports indicating that in some areas a single zipcode area will actually span across one or more different tax jurisdictions. So, if I define a particular zipcode as belonging to one jurisdiction (as per the plan we developed), the result will be wrong for those residences that, though within that zip area, are actually in a different tax jurisdiction. Dang!
This release provides a solution for that. In essence, our new method allows you to have split-zipcodes. Details are in a new chapter, as just added to our "How to Create Your Tax-Rates File" handbook. One way to open that handbook is via a button provided in the ServiceDesk Settings form:
Or (perhaps more convenient for the moment), just click here. When you open the little handbook (and assuming you want to know how to split zips), look for its Chapter 4.
Improved Zone Handling for ShopJobs:
Occasionally over the last few years, we've had users express a particular conundrum. It arises in connection with ShopJobs, and when using any of our DispatchLink utilities (or CyberLink) to keep outside entities (such as ServiceBench, ServicePower or your own online scheduling interface) apprised of availability status. The conundrum is that, most typically at least, servicers do not want ShopJobs to decrement against availability. This is because, in contrast to field-appointments, the time that's needed for shop work can typically be pushed around as needed to accommodate acceptance of much more time-critical field appointments.
To be somewhat more specific, the issue arises only in the particular case where a company decides to create pseudo "appointments" for their ShopJobs. Often companies find that a pseudo appointment is needed as the mechanism to put the intended/needed work on a tech's roster, to assure it's addressed in a reasonably timely manner (absent such "appointments," shop work can tend to be put off off forever and ever).
The question then becomes: when creating these pseudo appointment for ShopJobs, how do you avoid having them decrement availability in zones that are setup to manage availability on field work?
This release (actually, it was in the last release, but we forgot to announce it then) offers a solution.
First, we made it so the system will accept (for the appointment's designation of applicable zone) Zone 0. Zero is not a true zone. It's a fictional one -- meaning that any appointment assigned to Zone 0 does not count against any real zone's availability (please note the underlying JobRecord may still be assigned to a real zone, and it's the only appointment's independent designation that potentially decrements availability status).
Second, we added a new query that injects when you go to make an appointment in connection with a ShopJob:
The query is needed because what's sensible, in terms of what should be done concerning the zone-assignment, will vary with circumstances. In some cases the appointment may be intended as one that's delivering the product back to a customer; in such a case, you'll want to accept the middle option (above): to insert the true/actual zone as applicable to the consumer's address (this is pulled from what's already designated within the JobRecord). In another case, you may be pulling in a technician who's otherwise assigned to field work (within a true/outside zone) to do the in-shop work -- in which case it would make sense to pick the third option, and then indicate (as the subsequent dialog asks) the particular zone within which that tech works. And, of course, there are the instances where you do not want the appointment to count against true zone, in which case you'll pick the first option above.
Please note again this remedy applies only if you're setup
with multiple zones. If you're setup with a single zone (or with no zones
at all), none of this will affect you.
New Report on Technicians' Performance in Regard to Dispatches Received:
Though we've long had excellent reports for evaluating technician productivity (indeed, a whole set of them), we kept getting requests for some different kinds of numbers, as compared to what we were directly providing. In particular, folks wanted to more directly see, from among the quantity of appointments as assigned to each tech (aka "dispatches"), how many within a particular period resulted in completions, how many resulted in ordering parts, how many no-shows by the customer, etc.
This release features a brand new report to satisfy such requests.
It's called the DispatchesPerformanceReport, and is situated within (sensibly) the Reports form (F11), within its "Performance - Techs" sub-category.
Here's what the actual report output looks like:
As you can see, it's somewhat more raw-numbers oriented than are some of our other reports (this is what we heard some users wanting).
This report does require installation of Microsoft's Excel to contain its results, so if you do not have that application installed on the machine where you want to run the report, it would be a good idea to do so.
Our Reports/Online Handbook (available via provided
button within the Reports form) does have an added section to describe
more specifics about this new report (new Chapter 8 therein).
Mobile Tickets Can Now Be Initiated within SD:
In November of '09 (see notes accompanying release of Ver. 4.4.38) we added the ability within ServiceDesk's FinishedForms context (Alt-F4) to directly open a ticket, as created by a tech within SD-Mobile. This made it possible for an office person to have complete edit-ability over Mobile-created tickets. Most particularly, an office person could now edit such tickets, add pricing and otherwise finesse, for the tech's reuse upon a return visit. (Of course, the opened Mobile tickets also became useful tools for ultimate entry to the SalesJournal.)
Though great this addition was, there is a significant element we did not at the time include.
Specifically, we did not make possible for a person in the office to initially create a Mobile ticket, prior to the tech ever having made one himself, as applicable to the job. This might be appropriate, for example, if the office receives a request for service and is able to tally up everything that will be involved prior to sending the tech out. This might be done for the sake of giving the customer a direct and precise quotation. Supposing the customer accepts, it's best to have that same document the one which the tech will then use, upon performing the work, for presentation to the customer.
With this release of ServiceDesk, that is now possible. Whereas, if you previously went to create a Mobile ticket on a job where none prior existed, you would have seen this message:
Now, instead, you'll see the following:
Just confirm you want to make the new ticket, and the rest is
child's play. Upon your "saving" the new ticket, ServiceDesk uploads it to
Rossware's online Mobile server, where it is then available to the tech, when he
goes out on the job.
Still More (and Continuing) Evolution on the new Robo-Calling:
I thought we were doing a good thing by adding built-in screening, to prevent sending of reminder/confirmation-requests in circumstances where the underlying appointment is in a status that indicates it's already beyond such a stage (i.e., a request was already sent, the item was already dispatched to the tech, etc.). That intended "enhancement," however, resulted in a storm of protests, and so has been highly modified with this release.
In current state, the system will check when you request to send reminder/confirmations, to see if any applicable appointments appear to be already beyond that stage. If so, it will present a message like the following:
Take your pick, and you'll get results as wanted.
Continuing Enhancements on the new Robo-Calling:
Since our introduction two days ago of Robo-Calling, it's been a whirlwind here at Rossware. It's possible this feature has generated more immediate excitement than any prior. Early adopters found bugs we needed to fix, and produced a nearly instant flood of ideas for improvements. We have tried to implement all as quickly as we can. This release fixes all known bugs, and incorporates all requested improvements, as needed within SD itself, that we are aware of to date.
Corresponding with this release of SD is a new release of SD-CyberLink, Ver. 4.5.8. You'll need to update to that to take advantage of the ability of your customer to choose to cancel (as opposed to confirm) the appointment via robo-call communication option.
One new ability that will not be contextually apparent (absent notice here) is a new option placed into the Confirmation/Options form. Current with the last-prior release, that form looked like this:
Now it looks like this:
As you can see, the new section on the right gives you an option that is self-explanatory.
New Sales-Entry Option:
There's a new method to accommodate the need to record SalesEntries with dates that correspond with when the work was actually done, as opposed to when the entry was made (which has been the default date used in all circumstances, prior to now). There's a new button in the F9 SalesEnter form for the purpose:
This option may be particularly useful if you pay your techs on a commission basis, and want to assure their commission reports match perfectly with the reporting period (and contain solely work that was physically done within that period, as opposed to when the SalesEntries were entered).
New PartsProcess Export:
We have people wanting to get ever more kinds of data out of the PartsProcess system. We decided to create a comprehensive export, that simply provides all fields for all records from that context:
If you do not recognize, this new option is in the F8 Archived-PartsProcess form.
Robo-Calling to Remind/Confirm On Appointments:
At Rossware, we hate to move backward. Some five years ago, we introduced the truly modern and (in our opinion) correct method for reminding your customers of their upcoming appointments, and soliciting their confirmations. The function is part of our CyberOffice suite of options, and works with incredibly efficient, super-silky smoothness. Quite simply, ServiceDesk sends an email the afternoon prior to each appointment. This email reminds of appointment details, and invites the customer to click on a hyperlink to confirm. That link, in turn, takes your customer to an interface on your website (we provide as a plug-in) where he/she can either click to confirm, or re-schedule if need be. Full results feed automatically back into ServiceDesk. This is, quite simply (and, again, in our opinion) "the way" your reminder-and-confirmation process should work.
However, we've encountered a bit of push-back from some of our users. The refrain insists that there remain a significant percentage of jobs where it's impossible to effectively communicate with the customer via email, and so more old-fashioned communication modes must be retained. In particular, the desire is pressed for a system that, instead of using automation via email, would use automation via telephone calls instead (aka "robo-calling").
You wish; we deliver!
Again, we've been somewhat reluctant, because we feel it's a step back in technology, but we now nevertheless offer robo-calling as a method for auto-reminding appointments with your customers, plus to allow their automated confirmation.
Prior to this release, if you picked DispatchOptions from SD's F5 DispatchMap (either by clicking on a tech's name at the top of his list or by keying Alt-P then picking the "Invoke for All Techs" option), down near the bottom of the resulting list of options, you'd see this:
The option as shown highlighted above invoked our long-standing CyberOffice/Email/Hyperlink mode of reminding on applicable appointments (plus triggering for confirmation, etc., as described above). Within the same set of options from this release forward, you'll see the following instead:
As you can see, the option wording is changed to encompass a broader purpose. It's not just emails now that can be used as the method. The option can be used, as well, to trigger robo-calls. When the option is picked, the differences continue. This is what you saw before:
What you'll see now is very different:
As you can see, you can still choose to use what we consider the modern method (emailing). Or you can choose robo-calls. Or you can choose to prefer emailing on jobs where an email address is present, with the system primed to robo-calling otherwise. Finally, you can choose to both email and robo-call in each case where appropriate targets (email address and/or telephone number) exist in the underlying JobRecord.
You may notice that the old options gave you a couple of different parameters from which to pick in regard to emailing (customer confirms via email versus hyperlink, and with emails user-reviewed first versus not). Those email-method options still exist, but have been moved out of the every-time dialog into more of a set-once-and-forget context. Specifically, if you right-click in the DispatchMap to bring up its CheatSheet, there's a new menu option there:
Clicking on it will produce this:
As you can see, it's a micro-settings form -- a place where you can set once what would have been the particulars of your choice within the old email-appointment-reminder/confirmation-request dialog (with the choice thus separated, it does not have to be offered to you each time).
When you choose to robo-call a reminder/confirmation request to your customers, within 15 minutes a telephone call will be made to whatever telephone number is in the first telephone number position for the consumer (e.g., CustomerTel1 if it's a COD job, LocationTel1 if it's a third-party-payer job). If there is no pickup of the call, the effort will repeat at 15 minute intervals thereafter -- until one of three conditions arise: (1) a person or device on the other end finally picks up; (2) the appointment is otherwise confirmed within SD; or (3) the date/time of the appointment moves into the past. Outgoing calls will go into wait mode during any period outside of reasonable calling hours (specifically, they are allowed only between 7:30 am and 8:30 pm, local time).
When/if the call is answered by a human, an electronic voice will remind of the appointment (with appropriate details), and ask the consumer to press 1 to confirm. If the call is instead answered by a voice-mail type of device, the electronic voice will leave a message with appropriate details, and ask the recipient to call an 800 number to confirm.
Regardless of how confirmation is produced, within minutes of its occurrence you'll see the appointment reference in SD's DispatchMap change to the appropriate symbol showing confirmation (it should happen within the next-cycled update of the SD-CyberLink program), plus there will be a notation in the JobRecord's narrative history describing the confirmation (very similar to if it was an email/hyperlink-based confirmation, but with text modified accordingly).
This is considered an extension of our CyberOffice
suite of functions, and requires a CyberOffice subscription to enable.
In fact, it's very important that you update to the latest SD-CyberLink release
(Ver. 4.5.5) before using this new feature. There is a fee of 10 cents for each robo-call that
is completed (i.e., if/when picked up on the other end; there is no fee for
outgoing calls that are not picked up). We are paying the
service that does the actual calling, and must be reimbursed the expense.
We will charge the amount as part of your standard monthly billing.
Auto-Application of Discounts Via Transition from FinishedForm to SalesJournal Entry:
A new client in Canada does a lot of work for Sears. Sears pays the client 15 percent less than the amount invoiced. In other words, Sears expects the invoice to show one amount, while what they actually pay is 15 percent less than that. How to accommodate?
What we've done is, when you're using amounts as populated in a FinishedForm to auto-insert to a SalesJournal entry, the underlying code will now look for some key phrases and amounts in the underlying JobRecord.
Specifically, in the CustomerAddress box, it will look for the phrase "Materials Adjust". If it sees that phrase, it looks to see if there is a numeric expression following it. If there is, it will apply that numeric value, as an adjustment ratio, to the two materials figures as involved in the sale (merchandise and parts), when doing the auto-fill to a SalesJournal entry.
Similarly, in the CustomerCity box, it will look for the phrase "Labor Adjust". If it sees that phrase, it looks to see if there is a numeric express following it. If there is, it will apply that numeric value, as an adjustment ratio, to the two labor figures as involved in the sale (scall and labor), when doing the auto-fill to a SalesJournal entry.
Based on the above, this Canadian client should setup his Sears QuickEntry template in a pattern something like this:
Based on the QuickEntry template being setup in this fashion,
those key phrases will be inserted to any applicable JobRecords as created with
Sears as such a client. Thus, when it's time to do the SalesJournal entry,
the phrases will be in the applicable JobRecord. You'll assemble
total/face amounts of the sale (as per usual) within the FinishedForm.
Then, when you click on the ExecuteSale button, ServiceDesk will see the
adjustment amounts, and adjust accordingly when inserting figures to the
SalesEnter form.
More on Pricing Control:
A long while back, we introduced an option in our MarginPlanner system to allow, in essence, MSRP to rule, in terms of what SD inserts via its auto-pricing mechanisms. This need was registered, in particular, by a client who felt that if he varied from MSRP he'd lose the loyalty of his client base. The formal title for this option is DeferToPublishedPricing. It depends on having SmartParts data installed (the source of such "published" pricing), and is triggered by simply checking an appropriately-labeled box within the MarginPlanner form (Shift-F10):
The thing is, until now this option has had effect only within SD itself, and not within Mobile -- where the tech is in fact often inputting parts that must be priced then and there. With this release, implementation of the option will potentially carry through into Mobile as well. In particular, when you now check the main option within SD, a new sub-option will appear immediately under it:
As intimated via the contextual labeling, if you leave the indicated box blank, your DeferToPublished pricing option will not carry through into Mobile (i.e., the default/status-quo that's prevailed until this release will be maintained). If you place a value there, however (even a value of zero), it triggers for the option to carry into Mobile. The underlying logic is, you may want your Mobile pricing to be tied to MSRP, but perhaps just a bit more (the above-illustrated setting, for example, would result in Mobile-created pricing being inserted at 10 percent above MSRP). You can pick whatever percent difference from MSRP you want Mobile-created pricing to be, including precisely at MSRP (in which case you'd insert a value of 0).
More for Kinooks:
Yes, if you're a client in the US, you're indeed among the overwhelming majority of SD users -- but it doesn't mean we can overlook our dear friends to the North. As mentioned in an earlier release, they have some special tax needs there, owing to the fact they have provincial sales tax (PST) and federal sales tax (GST). In some of their provinces, both are effectively charged as one entity (HST), but in others they're fully separate. Back with release 4.5.44 (see relevant entry below) we had a major upgrade within Mobile to accommodate the separation. This release concerns an enhancement within SD itself.
In particular, we recently learned from a client in Saskatchewan that, at least as configured there, some sale items are exempt on one of the two taxes, some on the other, some on both and some on neither. This is relevant to SD's FinishedForms POS interface (Alt-F4), where the Generic and Custom form types have long been configured with a column of line-item checkboxes, to indicate whether each corresponding line-item is tax exempt. For Canadian users as just described, two different such columns are needed.
Instead of this: | Users in some Canadian Provinces need this: |
![]() |
![]() |
The first of the two columns should be checked to indicate
that a corresponding line-item is PST-exempt, and the second to indicate
GST-exempt (if you forget which is which, float your mousepointer over the top
of any checkbox for a ToolTip reminder). With this release and forward,
the two columns will appear (within the Generic and Custom FinishedForm types)
for any user whose SD installation is setup to indicate separate PST/GST
treatment.
Upgrade for the Within-SD Type-II PostVisitReport -- Bringing it up to the Current SD-Mobile Standard in Regard to Checking-Off Usage (or Why Not?) of Special-Ordered Parts:
If you're bored by historical context, skip the next three paragraphs.
The first PVR interface in ServiceDesk was what we presently call the PostVisitReport Type-I (Shift-F7). It collects PVR information via a dialog (Q & A) type interface. It was the only PVR method for the first few years. It was designed primarily with intent to accommodate a technician sitting at a console in the office and making his own PVR. In 2002s we recognized the need for an interface where an operator (more typically an office person doing the PVR on behalf of a tech, rather than the tech himself) could simply click or tab into each area as relevant, as opposed to running through an entire dialog in every instance. Thus, we developed SD's PostVisitReport Type-II, which is much more a fill-in-the-blanks type of interface.
When first introduced, our new Type-II PVR did not have quite all the added bells and whistles as had been developed in the old and more mature interface (such as, for example, being able to report that a part as used from stock came from a different location than the applicable tech's truck). Gradually, we added them in, eventually bringing Type-II up to full par. Then, as folks began asking for even more bells and whistles, we began neglecting the old interface. We would, in short, add a new bell or whistle into our shiny new interface (such as the system which warns if a part, as being special-ordered, is actually in stock), while neglecting to add into the old. Thus, over time the PVR Type-II became a much more capable agent, as compared to the old interface.
Approximately three years ago we introduced a new (and third) PVR interface, as incorporated in SD-Mobile. Its history follows a trajectory similar to the Type-II PVR within ServiceDesk: first it did not have all the bells and whistles, but we gradually improved and augmented until it did, then as the process continued it eventually eclipsed the within-SD PVR in terms of the total power and utility it offers.
With that as context, what's involved now is retroactively bringing SD's own Type-II PVR up to current SD-Mobile standards -- in one particular respect.
Specifically, some 13 months back we augmented our cradle-to-grave parts management system (see 10/12/10 entry in the SD-Mobile WorkDiary). Prior to that, Mobile's "check-off usage" section had nothing better than an almost perfect parallel to the section that's existed (until this release) in SD's Type-II PVR: a place where the user is permitted to check-off indication of usage, and in absence of such action the system assumes non-use. We altered the Mobile interface to make it so the tech is required either to check-off usage, or to otherwise indicate a specific reason why he did not use the item.
We had a request to add the same enhancement into SD's Type-II PVR, and that is what's accomplished in this release. Now, where there are one or more items showing in this particular Type-II PVR box:
and if the operator clicks to save the PVR without having first indicated disposition of each such item, this interdicting message will appear:
The user will be returned to the main PVR interface, to complete the required work. Just as in the Mobile interface, a double-click should be used, on any line-item, if needing to indicate non-use and the reason why. It triggers a box like this:
where the particular reason can be indicated. The specific listing of options in this box will be precisely the same as in Mobile. What's shown above is the default, but if you've customized the list for Mobile, the same customization will be seen in ServiceDesk (for instructions on how to customize, see this document).
One more enhancement, to mimic current Mobile standards: If there was a core on the item involved, the operator will be informed, and not permitted to proceed unless indicating the core return was placed into proper channels:
In general, we do not intend to bring SD's internal/built-in PVR interfaces up to every standard that has developed (and will certainly develop further still) in the Mobile context. We feel our more advanced users (the ones more in need of and more likely to use advanced bells and whistles) should be migrating (most have already done so) into Mobile regardless -- so it is where we are logically putting most of the advanced power as regarding information flow between office and technician. In the circumstances involved, however, it seemed sensible to migrate this particular enhancement back into the older environment.
A Model Communication:
We work "stinking" hard here, striving constantly, with enormous energy and determination, to make the system better for all of you, our beloved users. We think of it as a virtual partnership. We're working for you, and you (in turn) help us with your input. But the fact is (I am sorry to say), some of our users are a little less effective in helping us than we'd like. When we receive communications that lack specificity and context, it is sometimes worse than receiving no communication at all (consumes our time reading them, but with no benefit in understanding). In general, where you're initiating a communication and expect to put us to work in responding (typically via an improvement in the software) we need you to be willing to put in sufficient work to make your communication effective.
Recently, I received an improvement/fix request from a user that struck me as the perfect model I wish all would strive for. Given that it concerned a somewhat complex topic, the sender had first taken the time to fully explore and familiarize himself with what he was encountering in ServiceDesk. Then, he further took the time to formulate his description in a manner that made it totally easy for me to understand -- and with great precision -- what he'd encountered. I can't tell you how much easier this made it for me to go right to the underlying fault, and fix it.
With the author's permission, I am here providing a copy of that email for all to view (click here).
Though Paul Manning happens to set the highest possible standard (in communication excellence), many of you likewise do superbly in making your communications precise and readily understandable. I cannot tell you how greatly I appreciate that.
I also immensely appreciate when, like Paul, you are considerate in choosing to direct requests to persons other than me (Glade Ross) when accurately anticipating it is not a matter that requires my personal attention. We've grown large enough here that it's not practical, any longer, for users to expect my direct attention on matters where other staff are competent to assist. I can't be stretched that thin, so appreciate where people have the insight to leave me free for the matters where I am truly and uniquely required.
If any of you do not know, unless there is a specific reason
why I should be particularly addressed, email requests should instead go either
to a particular staff person other than me, or to our general support mailbox (support@rossware.net).
If everyone chose to go direct to me in every instance (as some do; I've been on
a campaign to try to break this habit), I'd be spending all day every day --
doing nothing but attempting to keep up with emails. That would not a
productive Rossware make.
Finally Filled that big/little "Hole" in Inventory Control:
Even when first introduced on the market, ServiceDesk had a lot of awesome features. There were several particular and significant functions people reasonably expected, however, that did not exist. When asked about such expected elements, I've candidly referred to them as "holes." As a general development strategy, we've gone after the hard things, occasionally skipping past an element that seemed less immediately important. Over time, we've made it back to most such areas, filling in such holes as were initially left behind. But one in particular has remained, until this release.
In the inventory control system, we've long had several superb systems for ordering stock replenishment. We've also had a superb interface for checking in stocking parts as they arrive. We have not, however, had a mechanism for keeping track of what's on order for restock and waiting for arrival (referring here specifically to stock replenishment, as opposed to special-order where in fact such details have long been very precisely tracked).
For persons migrating from other systems where they had such an ability, this hole has at first seemed shocking. At least on initial discovery, they've typically thought the hole would be untenable. For years, though, I've had the same reply. Please try the system as is. If after real use you find this hole is an issue for you, it will then be a priority for me to fill it. Otherwise, I need to spend my time on projects real-life users are actively clamoring for.
To be candid, I've wished somebody would later tell me the hole had proven to be untenable, because I've grown tired of confessing to its continued existence. It did not happen, though, until last week. A user in Newfoundland called and said for them it's an average of ten days between placing their order for restock and receiving the shipment. During that time, they need to order restock again -- and, obviously, need to know what's presently pending in that ten-day order queue.
As had long been promised, I turned my attention immediately to the matter.
From this release forward, ServiceDesk will automatically keep track of re-stock orders when you create them via the F10 form's items-presently-deficient method (keyboard shortcut is F10→O→D). It will also automatically check-off items, as prior placed into this new ItemsOnOrderQueue, as you check in parts using the F10 form's receive-items-into-stock method (keyboard shortcut is F10→R). In fact, while working in these two environments, you won't notice this activity. It's simply done behind-the-scenes, for you.
Where you'll see a difference is where you go again to that same order-on-the-basis-of-items-presently-deficient environment, and view items on which you are still deficient, and where an order is presently pending. In that circumstance, text in the right-third of any applicable line-item will appear in a magenta color, as opposed to the normal black. This is to alert you to the fact an order is actively pending on that item. And, if you simply float your mousepointer over the item, a ToolTip will appear that details precisely what order is pending (or, if multiple orders, it will detail the multiples):
There are certainly enhancements we might make in the future,
now that we've created this particular structure. For example, we might
make it so you can receive a shipment simply by direct-matching it to the prior
order. For now, though, the above is as far as we've gone. It meets
the minimum need.
Improved IQ on WipAlerts:
This is one that's likewise been a long time coming, but -- hey -- we got there.
WipAlerts are a totally awesome feature. If you've not been taking advantage of them, I stoutly, strongly, and with huge emphasis recommend you change that omission post-haste. Really, they're totally powerful, and if you're at all past the beginning stages of ServiceDesk implementation, you should be using them.
Regardless, as awesome as WipAlerts are, they've long suffered from a particular limitation in IQ. It concerns either of two situations:
1. You have an appointment pending for some date rather far into the future; or
2. You've ordered one or more parts, and the expected delivery date is rather far in the future.
In either case, the customer is not really expecting to hear from you for some significant time. Regardless, it's been the structure of the WipAlerts system to periodically pester you, even while you're waiting for that far-off event. On the one hand, this is not all bad. In my service business, we learned that even when we told a customer it would be at least two months before a part would arrive, if we did not call them at least occasionally during the intervening period, they'd conclude we'd neglected them. WipAlerts are a great tool to help assure that occasional contact. However, they do not need to remind you as often as otherwise.
Until now, they've had no IQ to distinguish between that circumstance and others. With the present release and forward, they'll be smarter.
Specifically, where either an appointment or expected parts-delivery date are still pending, the WipAlert system will multiply whatever is otherwise the specified grace period, for the category, by a factor of five. As an example, suppose you've left the grace period as applicable to the "Waiting for Parts" status category at the default value of 3 days. If so, and if the system finds the anticipated arrival date of any pending special-order order part is still in the future, it will multiply that three 3-day grace period by a factor of five, changing it to 15 days instead. In consequence, you'll not receive a WipAlert in such such circumstances unless its been 15 days (as opposed to a mere 3) since the date of the most recent entry in the underlying JobRecord's historical narrative.
To assist you (and, frankly, we here at Rossware too) in remembering what is the structure of this enhanced WipAlert IQ, we have also augmented the ToolTips that show when you float your mousepointer over any JobRecord's status selection. Instead of merely showing whatever is the applicable grace period for that status, the ToolTips as particularly applicable to the status categories of interest will additionally have some added text to explain this added IQ. Here's an example:
As with any ToolTip, this one comes up when you float our mousepointer over the underlying object that triggers it (in the above case, the "Waiting for Parts" check category).
Small Enhancement in Tech's Revenue Report:
Recently we were asked to add a couple of figures to the "Tech's Revenue" report (keyboard shortcut to get there is F11→T→R. The new figures are shown (circled) here:
The first-circled section is obvious in meaning. The second breaks down the tech's average per-day sales in Materials (M) and in Labor (L).
Better Housekeeping:
A database-cleanup routine (for the UnitInfo.mdb file) was
added to the regular nightly archive sequence. It will help keep your
UnitInfo database performing in top trim.
Explicit Exempt-Amount Fields Added to Tax Export File :
In the Reports form (F11), when you a run Sales-Summary there has long been button for exporting extended data, including in particular a table that itemizes each sale with significant accompanying data (zipcode where each sale occurred, department, etc.). We have just added three more fields to that export (exempt materials, exempt labor, and exempt total). These values could always be derived, but now they are there explicitly.
Full Accommodation for PST/GST Separation -- as Needed in Some Canadian Provinces:
If you are a Canadian client, this will interest you (otherwise not).
If you operate in a province that requires separation of PST and GST on your invoice, we hope you have known there is an alternate version of the Generic FinishedForm that's designed to accomplish this. If you need this and have not been setup for it, please contact our office and we'll help you make the change.
If you also are using SD-Mobile, this will especially interest
you. Until now, there has been no ability to separate PST and GST in the
Mobile ticket format. Now there is. For details, please look in the
SDM-WorkDiary for the entry
carrying the same date (10/10/11) as this one.
Improved "Returns" Handling via the POS System:
I must confess I am sometimes slow to finally get something right. I thought I had POS returns management fairly well "nailed" when rolling out the improvements as announced on 9/13 (see entry below of that date). Turns out, that area of operation was less well "nailed" than I thought. This release seeks to address that
I have, in fact, worked out a whole new (and much better-streamlined) procedure for managing returns, and I've done a completely new re-write of the manual section (the prior re-write was only a couple of weeks old) that's devoted to the topic. You'll need to read that section, please (it's very short), to know how the streamlined/easy method is intended to work.
You can open the entire FinishedForms Mini-Manual, if
you wish. Use
this link, or the button as provided for the purpose within SD's
FinishedForms interface (see first graphic in the preceding entry below, to know
where that button is at). The whole mini-manual document is about 17
pages, however (excerpted from the main SD manual) and for returns in particular
it's only about two pages (near the end) that will concern you. We suggest
you go to the very bottom of the document, then up three pages. The
section of interest begins in the middle of that third-from-the-bottom page.
Expedited Initiation of POS Transactions when using the "From-Callsheet-Mode:"
Back in 2008 we introduced our Direct-POS system, which allows maintenance of a POS-Window from which point-of-sale transactions can be conducted with no need of initiation from Callsheets. Regardless, it remained possible to initiate via the old method, via Callsheets, and many users preferred to stay in such mode.
In such connection, we've also long had an option where, from a Callsheet, you can optionally right-click on the Job/Sale button as a means of telling the system that, upon creating an underlying JobRecord via the little yellow "Create Job/Sale" form, you want to transit immediately from thence to the FinishedForms interface (as needed when you're doing a POS). Recently, a user pointed out that the momentary stop in that little yellow form served no significant purpose. He wanted express passage straight past, direct into the FinishedForms interface. It seemed like a smart idea, and with this release the change is implemented.
Re-Write of Important Manual Sections, and New Mini-Manual:
With all the work as recently done in connection with POS operations, there was a very serious need to update the manual accordingly. In fact, upon going to complete this task we found the applicable manual section was so out-of-date as to be piteously embarrassing. It wasn't just it's contents. The entire FinishedForms discussion (encompassing both warranty claims and POS) was but an add-on section in a chapter otherwise devoted to other topics. That reflected developmental history. The FinishedForms interface and all its related functions began small, and only over time grew into such proportions as exist today. At any rate, given today's proportions, it's a subject area that deserved its own chapter, and the manual has not been re-organized to make it such. And it wasn't merely re-organized. The entire chapter has been written fresh, to accurately reflect today's state of the art in terms of what exists in the underlying systems (the old section was tossed).
The current manual re-write is available for download (in pdf format) from the ServiceDesk downloads page. Additionally, we've altered the buttons that first appear when you do a direct load of the FinishedForms interface.
The button as highlighted above will open the newly-written
section from the manual, as an excerpt specifically on the topic of the
FinishedForms interface, and the details of its particular warranty-claims and
POS functions. It's there to be handy for you, as a Mini-Manual, whenever
you need it.
Further Tweaks on POS:
You might think it would be nice for me (as the President of a software company) having no bosses to answer to. Hardly. I've got at least 520 bosses. When I try to please some, I aggravate others, and vice versa. Sometimes it seems like a no-win situation. In the present case, I thought I'd engineered the new POS "command" interface in a manner that would satisfy every desire, but I was naive.
In a nutshell, I provided means (and as particular to any form type) to accommodate any combination of sub-actions as integrated with a single-click for Sale, and with either sequence of Sale-first or Sale-last. Of course (and as always), any sub-action can be individually clicked, too. But that wasn't good enough. Some people wanted a single-click option that would do a collection of selected sub-actions, but excluding (as opposed to including) the Sale. Remember that Burger King slogan ("Have it your way")? That's me. Therefore, the just-introduced new interface has gone from this:
To this:
As you can see, the "Execute Sale" button has been changed in
color and moved to the right. In it's place on the left is a new "Do
inclusions only" button. I believe the structure speaks for itself.
Massive Overhaul on POS Functions:
Let's face it.
POS operations have not been Rossware's forte. It may have been overstating it, even, to call our past POS functionality a "system." It was made from bits and pieces, cobbled together from elements first built for other purposes. The overall result has been workable, but not many would have called it pretty. With the present release, we are at least several steps closer to having a system that, if still short of "beautiful," you might at least find worthy of affection.
Improvements are as follows:
1. Improved Methodology for, and Immediate Visibility on Items Flagged for Inventory-Transfer and/or PartsProcess Action:
Here's a place where the prior design was truly dumb. There were mechanisms that allowed any line-item in the applicable FinishedForm to be "flagged," as applicable, for an actual transfer to/from inventory or creation of a special-order request in the PartsProcess system. Intended inventory movements were flagged by selecting an item from the as-you-type dropdown (specifically, with it keyed to internal inventory). Special-orders were flagged by manually typing a double-asterisk somewhere in the line-item. In the first case, there was no immediate visibility as to whether an item was flagged, and drop-down selection was the only method to accomplish flagging. Plus, there was no direct way to turn off a flag. In the second case, the double-asterisks might have seemed a good visual indicator, but even this was not always true, for the system was programmed to ignore double-asterisks if present from a prior session. In either case, whether an item was truly flagged, or not, only became apparent when the "Enter to Inventory" or "Create Order" process ran, as applicable, typically at end of your POS session.
Welcome to a new world.
All for-action flagging is now immediately visible, and remains so in real-time. If something changes to remove a flag, you'll immediately see it. If something changes to add one, you'll see that too. Flagging visibility is accomplished, simply, by coloring the line-item that's flagged, and with a particular color, depending on the flag type.
It is also now easy to manually flag (or un-flag) any item. Just do a right-click in the description box:
Upon right-clicking (and as you can above see), you're presented with a simple set of flag-related options (plus the same opportunity to delete the line item, which used to be all you'd get with a right-click). The flagging options also include the same colors as the flags themselves, so the dropdown can simultaneously serve as a "key" to remind you of what each color means. As far as operation is concerned, just pick what you want. It's that easy.
Additionally, there is now an option to automatically flag an item for special-order creation. It follows the pattern of auto-flagging-for-inventory-transfer that's long existed (e.g., as occurs where an item is selected from the inventory-integrated dropdown). Logically, this new auto-flagging works in parallel fashion, but where you've set the dropdown to integrate with SmartParts data (as is typically used when typing in a non-stocking item). One difference is that this automated flagging is optional. It defaults to On. If you prefer to have it Off, pay attention when the "Integrate Select" box comes up (just after you've clicked into any previously empty partnumber box):
As you can see, it's easy to turn this automation off (or back on again) as preferred. Please also note the preference setting is specific to user and FinishedForm type involved.
One more note about these new methods. This does not concern anything new, but we want to be sure there is no misunderstanding. Simply because an item is flagged for action, does not mean the action has occurred. In fact, it almost means the opposite (once the action does occur, the item is automatically de-flagged). Please do not mistake flagging for actual action. The actual actions occur only in conjunction with, as applicable, the "Enter to Inventory" and/or "Create Order" processes (typically as invoked at the end of your POS session on a particular ticket).
2. Improved Actions Interface and Integration Options:
As is true of many long-in-use systems, our FinishedForms/POS interface is the product of many evolutions. Believe it or not, it's first incarnation had one function only: to enable printing of text to a paper Narda! That was it. Thus, at the time, this interface needed (and had) but one action button, and its descendant still exists today: it's the button labeled "Print ticket." Next in evolution was adding the "Transmit claim" button (to accommodate that new-fangled, hoity-toity method of conveying a claim to a manufacturer that we now take for granted).
Then someone wanted ability to print the entirety (not just initiating information) on their own form (i.e., not to the Narda, and not using SD's up-front ticket-printing method, which only does initiating information), so we added the first alternate form. Then someone thought, since they were assembling sales numbers in the FinishedForm context anyway, wouldn't it be nice if that was used as the basis for filling in a sales-entry, so we added an action button for that. Then someone said, maybe you should make it so I have the option, if I'm choosing to print or transmit anyway, that it automatically offers to make the sales-entry (essentially self-clicking on the "Record Sale" button), so we added that (making the option particular to each form type).
And it continued. By and by our first client came along who was doing significant POS work, and it became evident we could adapt these mechanisms for the purpose. But if so, the interface needed integration with parts inventory and special-ordering, so we added built-in flagging for such actions (though they were very clumsy until now, as above-noted), along with buttons to accomplish the actual events. It was also realized, in regard to these new action buttons, it would be nice if their "click" events were also optionally auto-integrated with doing a print or transmit, (i.e., just like "Record Sale") so this also was duly programmed into the system.
Evolution does not always make for pretty. Below is what the resulting structure looked like, just prior to this release:
On reviewing the above, it became evident that an improvement was long overdue. Here is what you will now see:
Formerly, the "Record Sale" button was but one of many. Now, please observe it is instead labeled "Execute Sale," and is given the due prominence that seems logical for a POS interface. Additionally, instead of it being potentially integrated with other actions as before, other actions may instead be integrated with it (we think, for POS operations, this is the logical emphasis). Plus, the mode of integration is now much more explicit and selective.
Specifically, the former method for integrating actions (i.e., to tell the system you wanted one particular button-click to auto-include others) was by right-click-toggling-to-red the form-selection-radio-button as pertinent to the form type on which you wanted this (referring, of course, to the one, "vanilla" form of integration as was formerly offered). That does not happen any more. Instead, each of the action buttons (aside from "Execute Sale") will show a little checkbox on its top-right corner at any time that the "Execute Sale" button is activated (again, please see above). With any particular form type selected, you can simply check (or uncheck) the button/actions you want included when the "Execute Sale" button is itself clicked. These settings are again local, and particular for each form type (in fact, each will default to a check state we deem as most typically wanted for the form type involved).
Please note there is also an option as to sequence (i.e., whether the sales-entry occurs before the integrated clicks, or after). If you do a simple left-click on the "Execute Sale" button, the integrated clicks will occur before the sales entry. If you do a right-click, they'll occur after (no need to memorize this fact; a simple float of your mouse-pointer over the button will bring up a ToolTip to remind). Of course, you should also note that each of the potentially auto-included buttons may be clicked-on individually, in their own right.
Another change is that the "Enter to Inventory" and "Create Order" actions (formerly accommodated via two separate buttons) are now accommodated via a single button only, labeled "Execute LnItms." It's another button that, if you forget exact meaning, you can float your mouse-pointer over for assistance.
3. Numerous Other Fixes and Improvements:
Really (I'm not just bluffing), there are tons and tons of
smaller improvements. One example: if you fail to fill-in a
quantity yet select an item from the dropdown, the quantity box will
automatically populate at 1. It's a small convenience, but such matters
add up.
Greatly Improved Automation When Updating:
Our resident "geek extraordinaire," Josh Smith, gets direct credit for this one. If you've updated ServiceDesk even once, you've learned the actual update file (as downloaded from our website) is a single, self-extracting zip folder. In other words, all files as contained in the update overall are "packed into" this single file, which is equipped to self-extract those files into your computer (it's the self-extraction utility you're seeing when that "Winzip Self-Extractor" window pops up).
The thing is, the location where the files need extracted to can vary, depending on how ServiceDesk is installed in your computer and network, and I'd never managed to discover a method via which ServiceDesk can dynamically tell that Winzip Self-Extractor what "Unzip-To" path it should offer. For such reason, it is simply hard-set to the most typically needed path ("c:\sd"). To compensate, the update-dialog within ServiceDesk has been programmed to tell you, the user, that you'll need to manually change the path to, when that is fact the circumstance. The problem is, people tend to not read the dialog, and end up unzipping to the improper location. Even for those that do it right, it's an unwelcome added step to have to make that change.
Good ol' Josh managed to find the trick that my research
had failed to discover: namely, a way to programmatically (and on-the-fly) tell
that WinZip self-extractor what unzip-to path it should offer. Based on
this, the ServiceDesk-managed update sequence is now much improved. There
are no longer any steps in the sequence telling you what you need to do to
manually change that default path. Instead, it will default just
as needed for the circumstance. In fact, there's not even a need for you
to click on its Unzip button. That, too, is automated. Overall, you
should find the update sequence much more automatic, and fast.
New Parts-Acquisitions Report:
By popular demand, the archived-PartsProcess form (Ctrl-F8) has a new report. Here is where you request it:
And here is what the actual report generally looks like:
In short, it's a summary, itemized by vendor, of everything you purchased over a specified period of time. Like its cousin Ctrl-F8 reports, when this one displays there are buttons to the side that allow you either to print the results, or to open an underlying Excel file that contains the underlying, item-by-item records on which the report is based. If you've had a need for something like this, we think you'll love it.
Improved Claims-Handling for Panasonic:
One of our CE (consumer electronics) clients recently brought to my attention that the system was doing a poor job with the particular needs as involved with transmitting Panasonic claims to ServiceBench. Three particular needs were expressed:
1. Some Panasonic claims involve the need for a special (otherwise non-standard) WarrantyType designations. This is a field-value that most often indicates whether the claim is Parts-Only, Labor-Only or Both, and ServiceDesk has heretofore handled those distinctions implicitly (i.e., behind-the-scenes, without you needing to worry about it). For this Panasonic need, however, we needed to make a method for the a Panasonic servicer to set it explicitly. That need is met via a new box in the on-screen NARDA:
Please note this new box will self-populate with the same value as would have always been implicitly-deduced on your behalf (i.e., behind-the-scenes, within the system). We're simply making that deduction visible now, and providing a place where you can manually change it, if wanted/needed. Please note, in such regard, the system internally re-calculates what's normally-appropriate in this box anytime the total-tallies in the form change (i.e., if parts were added or taken away, labor added or taken away, etc.) -- so, if you need to set it manually, do so after the other items have all been setup.
2. Panasonic needs a CaseNumber in each claim (which is pulled at the SB end from their claims-transmission Other Item2 Code). We are accommodating this via our on-screen NARDA's Contract/Service Agreement Number box:
Please note it is a special-treament for the system to place the contents of the above-identified box into SB's Other Item2 Code field. It will apply only when the system sees "PANASONIC" as the underlying client on the job.
3. Panasonic needs round-trip-mileage in each claim (which is pulled at the SB end from their claims-transmission Other Item1 Code). We are accommodating this via our on-screen NARDA's Miles driven box:
Again, please note it is a special-treatment (only where Panasonic is the underlying JobRecord client) for contents of this box to be placed into SB's Other Item1 Code.
If you're wondering why things must be so complex, it's
becase ServiceBench uses various of its claims-transmission fields differently,
depending on who is their underlying client. We have to cope with those
differences from our end. Regardless, in addition to the actual
operational special-adjustments as are described above, the contextual
Translation-ToolTips have also been modified to explicitly describe what's being
done (and in what circumstance) with the contents from each box.
Improved Handling of ServiceBench DispatchIDs:
We have adopted a new strategy for managing the ServiceBench DispatchID.
For some, the old method was fraught with frustration.
It depended on you maintaining an appropriate setup of text (DispatchID
in the right place and with appropriate flags), and if you broke the rules,
ServiceDesk would not capture and interpret the DispatchID correctly.
Beginning with ServiceDesk Ver. 4.5.31 and SBDL Ver. 4.5.5 (both posted
on the morning of Monday, 8/22), there's an improved method.
In a nutshell, SBDL will now place the DispatchID into an added and
protected
location (some have referred to this concept as "hard-coding"
the number). Specifically, it will
go into the underlying
MoreInfo
notes. Formerly such notes were
configured by SBDL to read as follows:
Now the DispatchID is contextually inserted:
And, if any user tries to do any edit on this section of text, the edit will be
disallowed. They'll encounter this
dialog instead:
The DispatchID is thus kept in a secure and protected location, where
ServiceDesk can in all instances accurately capture it.
Happiness in Smiley Faces:
If you examine the following image as extracted from a DispatchMap, you'll see some objects you've not seen before:
If those new objects are not jumping out at you, look specifically for smiley faces (though, actually, not all are smiling). There are three of them. They are the new feature being announced here. What are they for?
Quite simply, they are to equip the person who arranges your technicians' scheduling and routes with a feedback mechanism that encourages real diligence in achieving optimization. It makes a lot of difference to your operation's profitability, after all, if those routes are efficiently arranged. It makes a huge difference. Since pretty much the beginning in ServiceDesk, we have provided mileage figures within the DispatchMap, hoping operators would use such numbers as a means to self-score their finesse, seeking (we've always hoped) to whittle each tech's average-miles-per-job figure to the smallest level possible. But (and alas), the sad news is many simply ignore those figures. For such reason, something more concrete has been needed by way of encouragement -- to reach into the operator's psyche, as it were, with a more pungent encouragement to optimize.
That's exactly what the smiley faces are for. Next to the mileage-summary at the bottom of each tech's listing of jobs, you may now have a smiley face (varying between happy, neutral and sad) that applies to that particular tech's route. In the top-left corner of the map as a whole is another, larger smiley face, which similarly varies in expression depending on whether the day's entire roster of jobs meets specified targets for mileage efficiency.
Based on the above, anyone in the office can have instant and obvious visual feedback regarding whether efficient routing has been achieved.
Even more concretely, they can be encouraged to fix things. Just a glance at the frowny face in the above image, for example, suggests that Arthur Manoogian's route needs a fix. Look over at his route, and you can see, instead of sending him from the Smith job to Bazooka to Ross, it would be more efficient to put Ross in the middle. A quick mouse action would do this . . . and, instantly . . . his mileage-summary's frowny face would turn to a smile!
To implement this new capability requires a little setup on your part. Specifically, ServiceDesk cannot know what "mood" to put on a particular smiley face without knowing what is a reasonable mileage target, for efficiency, as applied to the tech involved (techs that work in predominantly rural rural areas will obviously have higher per-job "par" figures than those working in condensed metropolitan areas). You're going to provide that information to ServiceDesk in a new box as available within the Technician-Properties window of the Settings form. To bring up this window, go to your ServiceDesk Settings form (Ctrl-F1), look in the Tech-Roster section, and click on the technician of interest. That opens his Properties window. The new box to fill-in is shown here:
Just to be clear, what we're referring to here is what you want your operators to consider as a par figure, for the tech involved, in terms of average per-job-miles in his route. For example, if you were to estimate that 80 miles is typically about what the driving distance should be for ten jobs, you'd figure an average of 8 miles-per-job, and place that figure (i.e., 8) into the above box.
Beyond setup is the matter of how the system actually works, within the DispatchMap.
In such regard, please be aware that smiley faces will not appear for any tech for whom you have not specified (as per above) a "Target average miles" figure.
But how does the system decide what mood to put on the face?
Very simple. If, for the tech's actual route as planned, the system predicts an average miles-per-job figure that's within 10% of the tech's target figure, ServiceDesk will present a neutral face for that tech. If the predicted figure is better than that 10% margin, it will present a happy face. If it's worse, it will present a frowny face. A similar strategy inheres for the larger, roster-wide smiley face in the Map's top-left corner. The difference there is that it's roster-wide comparisons that are made, so you can judge if on average a particular day's routes merit a smile, a neutral face, or worse.
As a further aid, the system offers supplemental information if you float your mousepointer over one of the visual indicators. If you float your pointer over a tech's mileage summary area (or the smiley face itself), for example, you'll get a tooltip that informs you of what is the target figure for that tech (for easy and quick comparison to the actual/operational figure):
Similarly, if you float your pointer over the smiley face in the map's top-left, you'll get a cogent summary regard the data underlying its "mood:"
We hope you'll make extensive use of this new tool, and profit exceedingly from it.
Installment Two on Improved Specification for Tech's Begin-Route and End-Route Locations:
Since we added automated route-optimization via-call-to-MapPoint, some few years back (see entry here accompanying Rel. 4.3.76), there's been a mechanism to specify, for any given tech, whether you want the system to figure his driving begins at his home, at the office, or at the first job otherwise picked for him. Same thing, essentially, in respect to where his driving ends for the day (both specifications can be referred to as "route end-nodes). This specification was actually part of the route-optimization dialog. Just a few releases back, though (see entry accompanying Rel. 4.5.25), we announced an improved method that makes the specification independent of the routine dialogue.
It turns out that was a short-lived improvement, for it's superseded by what's announced here. Both prior incarnations of this feature saved the relevant settings to the applicable station's local registry, which meant it was a local setting only, and even if set at one station, there'd be no effect on what happened at others. For the new "Smiley Face" feature, we needed better than that. In fact, prior to this release, all of the per-tech mileage estimates have assumed each tech begins and ends at the office (regardless of settings for route-optimization) -- an assumption that in this age is increasingly untrue. We needed to fix that to make this feature all that it should be, and with such expanded use it was also important that such specifications take effect throughout all stations in your network, and not just locally.
That is the precise improvement that's being described in this entry. A few short paragraphs above (scroll up a tiny bit to see), we highlighted a particular new control within the Settings form's Tech-Properties window. Right next to it are two others, now highlighted here:
As above hinted, this is now the place where you can make specifications system-wide, regarding expected end-nodes in a tech's route. Indeed, though on the face of the new controls it appears you can only select from among two options ("Home" or "Office"), you are in fact free to select neither, which in effect gives you a third choice. (if you've prior selected one and want to de-select, just click again). If you do select neither, the system will refrain from implicitly adding such a leg to the tech's route.
Regardless of what you pick for a tech, the system will apply your selection when: (1) calling to MapPoint for its automated route-optimization; (2) calling to MapPoint to load and display a route; (3) calling to GoogleMaps to load and display a route; (4) exporting route data to a file; and/or (5) calculating a tech's predicted total miles and average-miles-per-job.
Please finally be advised that, from this release forward,
ServiceDesk will ignore any such local specification on a tech's
route-end-nodes as was formerly provided. If you have in the past been
relying on such specs, we strongly suggest you go into your Settings
form, click on each tech, and re-specify what's wanted for him.
Nothing Major:
With almost five weeks since the last prior entry here, you'd
expect a more celebratory headline. It just didn't happen that way.
We've been totally busy with tweaks and minor fixes. For example, we just
learned that the AHS-dispatch-insertion feature was broken. It's fixed.
We just realized today that the POS system could be improved if, when
creating a s/o request via the POS context, the sell-for price was auto-inserted
to the underling PartsProcess record. That's presently done. Last
week we were pressed (this required a lot of time) to better accommodate the
situation in some Canadian provinces where two elements of tax must be
separated. That's presently done. Etc. Etc. Etc.
Debit Transactions Now Available in the Virtual Terminal:
Y'all can thank Perry at A-1 Appliance, in Pearl, Mississippi, for this one. Debit cards (as distinguished from "Credit" cards) are becoming increasingly common. Our Virtual Terminal has been programmed to process sales as Credit-Type transactions, even if a Debit card is what's actually involved. In some instances, it's preferable to have the sale configured as Debit-Type instead, and from this release forward you can do that.
Of course, one of the critical elements in making a Debit-Type transaction fit the definition is that a PIN (Personal Identification Number) must be obtained from the customer. More than merely obtained, it must be punched in via an accepted PinPad entry machine (in other words, it is not possible to simply punch-in the number on your computer's keyboard; the credit card industry does not permit that). This means, bottom-line, if you want to run transactions as Debit-Type you must do more than merely update to this release (or later) of ServiceDesk: you also need an appropriate PinPad entry device.
Which particular device do you need?
In a nutshell, I have done my programming to integrate with a Verifone PINPad 1000SE, with it connecting to the computer via serial port). So far as I know, it's possible other PinPad devices might also work (at least assuming they also connect via serial port), but I make no guarantee; nor have I any present intent to expand the programming to accommodate other machines. Regardless, you may obtain the Verifone model in question direct from Merchant Warehouse at a reasonable price ($79).
Once you have your device, you'll need to determine what port number it's connecting on. With that number in mind, click on the Virtual Terminal's new Setup button:
That will open the new Setup frame, where you can set that port number accordingly.
With the above done, you should be ready to do Debit transactions. At this point, we've not provided a special button for the purpose. Instead, please signify you're choosing the Debit (as opposed to Credit) method by choosing to Right-Click on the Execute Sale button, as opposed to the standard Left-Click. If you float your mousepointer over, a tooltip will remind you:
Please note that you cannot run a keyed-in transaction as
Debit-Type. It requires a swipe.
More "TAT" Work:
Again, TAT is an acronym for Turn-Around-Time, and of course an objective in the service business is to keep your TATs as tiny as possible. Four releases back (see entry accompanying Ver. 4.5.22), we introduced a new "Quiescing" feature, associated with the JobsPerusal form (Shift-F7), and designed as a powerful new tool to assist in minimizing TATs. This release features two more such tools.
First, the JobsPerusal form now has a new filtering category, as shown in this comparison:
Secondary Filtering Options from Old | Secondary Filtering Options from New |
![]() |
![]() |
Second, we have added a "day-counter" window the the JobRecords-current form (F7). In its bottom-center area, it will display a box indicating how many days-old the job is. The indicator will change in color and emphasis, depending on quantity of days old (the coloring/emphasis scheme is based on age categories as listed in the dropdown shown above):
![]() |
![]() |
![]() |
![]() |
![]() |
Again, this "day-counter" box will appear in the bottom-center of every still-pending JobRecord.
Overall, the first new option (as provided with this release)
gives you the chance to easily review jobs within particular age categories.
The second provides an on-its-face reminder, any time you glance at a job, of
how old it is, plus provides an increasingly-acute visual alarm, as the job gets
older and older. Overall (and if appropriately used), we think these two
new tools can do much more to assist you in making your TATs as tiny as they can
be.
"Signatures" and Font-Selection Now Available on Non-review-first Emails:
Potentially (depending on in what degree you've chosen to use automation), ServiceDesk and its utilities can be involved in sending many kinds of emails to your customers.
These emails fall into two broad categories: those that are reviewed first (i.e., the email is first opened into a "Compose" window, where the user may review, add comments, etc., before clicking on Send); and those that simply go, without intervening user review.
In the first category, there has always been built-in potential for your emails to be formatted according to preference. In other words, you may pick the wanted font, setup for a specialized "signature" at the bottom, etc. (the capacity is automatically built-in, because its programmed into the email compose window that's opened for user review). This has not been the case, however, for non-reviewed-first emails. Whether sent via the Windows Mail Client (old method) or via the Rossware-Direct method, these emails have sported plain-text only, and no signature. We simply had not created technology that allowed otherwise in that context. Indeed, when we recently added the ability to include a "signature" when working via the Rossware-Direct method, application involved review-first emails only: not direct-sent items.
Now we have added such customization options to the direct-sent (i.e., non-reviewed-first) context -- at least assuming you use the Rossware-Direct (as opposed to the Windows Mail Client) method.
It can mean a significant difference in the quality of imagery as presented to your customer.
Old email as customer might receive, plain text and no "signature-area" inclusion | Email with a possible configuration as customer might now receive. Note "signature-added" space at bottom (please ignore that's it's a Rossware rather than a service company logo: I was lazy in the setup). Also please note the font is specifically-selected, which allows a more modern and appealing look. |
![]() |
![]() |
We have even included options that allow you to specify different "signatures" for different kinds of emails -- so that, in other words, the signature that's used for a particular context can be highly customized to that context. It allows you huge flexibility.
In such regard, one of the factors that drove us to make this improvement was a user (not to mention any names, but it was Tanner Andrews) explaining how he wanted to do things, within his email "signature," such as advertising specials, inviting customers to go to his website to purchase accessories, or to answer a survey, etc. Even, potentially, including coupons for future service. Of course, to fulfill so ambitious a strategy the signatures need to be selectable for context, so that is exactly what we've setup the system to allow.
In particular, with this release ServiceDesk itself is configured to accommodate two different "signatures," depending on context, and SD-MobileLink (with simultaneous release) three added signature contexts (SD-CyberLink has not yet received the improvement). Details are in the (also newly-revised) Email-Integration Handbook, available via the reference just provided, or via a linking button within the Email-Setup Window as available from within any applicable Rossware application. (The particular pages there that are most applicable to these enhanced capabilities are 10-13.)
If you're wondering, by the way, why the word "signature" is
often placed in quotes here, it's because in the context involved the word does
not have its normal meaning. It does not mean your name in cursive (though
it might in fact include that). It refers to the entire section
that may optionally be inserted/added at bottom of an email. Typically,
this section (if added) has your company's logo, website reference, perhaps
telephone numbers, etc. Sometimes it has disclaimers, injunctions
regarding confidentiality, etc. It can be as big or small, simple or
involved, as you want to make it.
New "Link from-JobRecord to Appointment-in-Map" Feature:
As you likely know, all of ServiceDesk's operative appointment info is stored in what we call the ScheduleList. Two interfaces are used to directly view and manipulate this data. One, the (F6) "ScheduleList form," is textual in orientation. The other, the (F5) DispatchMap, is more graphical, and offers several kinds of manipulation not available within the first. Regardless, either may be used to achieve a variety of appointment-editing results. And, no matter which is used, it's the exact same underlying data (i.e., from within that ScheduleList file) that's being accessed and managed.
A number of other forms have links to those two specific ones, as needed to conveniently invoke various of their management functions. From a Callsheet, for example, you may right-click on an address to view its location within the DispatchMap, and may then setup a new appointment from there (this is called the "ItemLocate" feature). You may do the same from a current JobRecord. Also from a current JobRecord (F7), you may invoke it's "scheduling" option This provides a link to an underlying appointment (if any) as loaded for you within the ScheduleList form. There you may easily edit it, or create a new one.
What's been lacking (until now) is a similar from-the-JobRecord link to an already pending appointment as-loaded-within the DispatchMap.
In other words, suppose you're looking at a JobRecord in the F7 form; it has a pending appointment; and you decide you want to see (or do something to) that appointment -- not within the ScheduleList form, but within the DispatchMap. (Perhaps you want to see it because you want to check-off that the customer confirmed, for example, which is not a function the ScheduleList form is setup for.) Until now, there was no direct method for that. Instead, you had to independently open the DispatchMap (i.e., hit F5), page to the day of the appointment, pan to the needed TechList area, then eyeball-search to find the appointment's reference.
That is what this update answers.
The control we are using to invoke this new link, within the JobRecords form, is its Appointment box.
Prior to now, that box had just one operative function, and it was superfluous (exactly the same as when you click on the form's dedicated "Scheduling" button). Why have we had two different objects on this form produce the same result? If interested, please read here:
Historical
Background (read if wanted for context; otherwise skip) |
The appointment box in ServiceDesk's current JobRecords form has a "history." By design, it was intended as nothing more than a historical artifact, reflecting whatever text as had existed in the equivalent position of its originating Callsheet. It had no operative function, and none was intended. This sometimes caused confusion for new users, who -- seeing text there -- expected it to always reflect whatever was the current appointment (as a historical artifact, text there never changed, even if the actual appointment did). Worse still, the uninitiated sometimes thought -- erroneously -- they were changing the actual appointment by editing contents in this box. Our first step to ameliorate this (several years back) was to make the JobRecord's appointment box non-editable (users can't erroneously think they're changing the appointment via edits in that box if they can't edit that box). However, this led to a new problem. Now we sometimes had new users who, still failing to realize the correct method for appointment manipulation, insisted on attempting to edit text in that box. Finding such a course impossible, they'd call and complain the system would "not let them change the appointment." We even put in dialog boxes to inform them (as they attempted) they were on the wrong path, and explained what the correct path is. Sadly, some either did not read or failed to understand these dialogs. Enter our second step in solution. We made it so a click in that appointment box (as when a user thinks he is going to edit there) has the same function as if he had instead clicked on the form's "Scheduling" button. Just take them to the correct place to do what they're evidently wanting to do, in other words. In general, it's worked much better. The one down side is we end up with two objects on the same form that, when a user simply clicks, produce exactly the same result. At least, you now have explanation for the inelegance as involved in this redundancy. Plus, we want to mention one more historical change in that box. Even when we pushed new users to the correct venue for changing or adding appointments, some continued to be dismayed when text in that box did not update to reflect their (now correctly made) changes. We initially dismissed such concerns, and endeavored simply to teach that text in that box means nothing. However, it was a losing battle. Functional or not, people wanted to see currently-applicable text there. So, we added coding so that, as pending appointments are changed or new ones added (from within the correct venues, of course), behind the scenes, ServiceDesk reaches back into that box, to update its text accordingly. There was still no real functionality involved, but at least the updating keeps people happier. |
Regardless, the JobRecord's Appointment box now has a real (and not merely duplicative of another button) function: it's to serve as a link to the underlying appointment in the DispatchMap (it's something of a mirror, in other words, of the Link-to-appointment-within-the-ScheduleList-form function that's been there, now, for years).
1. For simple such linking, do a right-click in the box. ServiceDesk will find the underlying appointment (on whatever day it happens to fall), and display it in the DispatchMap for you.
2. If the action you want in the DispatchMap is one of changing the appointment's check-off status (e.g., checking off that the customer confirmed, or anything similar), do a Shift-Click in the appointment box. This is the same action you'd do, if already within the DispatchMap, for the same result there.
3. If you want to invoke the DispatchMap's "Dispatching Options" list (i.e., as specifically connected with the appointment, but without going to the Map first), do a Ctrl/Alt-Right/Click in the appointment box. Again, this is the same action as is involved for the same result, if done within the DispatchMap itself and clicking directly on the appointment reference there.
So, those are the new "Link" functions as now available on the
F7 form's appointment box. If you float your mousepointer over the box,
there is a ToolTip to remind you. Please enjoy.
New "Open-Route-in-Google" Feature:
Since release of Ver. 4.3.76 some three years back, ServiceDesk has had the ability to integrate with Microsoft's MapPoint to optimize the sequence of jobs within a route, and to simply load/open that route within MapPoint. Those are great features, though with one significant negative: most folks don't already own MapPoint, and it's somewhat pricey to obtain. It wasn't so bad three years ago, when typically you could buy the program once (typically about $300) and install on as many computers as you wanted, but since then Microsoft tightened the internal mechanisms as designed to force you into buying added licenses.
In the meantime, Microsoft's main competitor and threat, Google, has continued to improve its online (and free) mapping system, called GoogleMaps, and we decided it was time to integrate with it. In fact, we already added such integration into SD-Mobile (so, with a single button click from their mobile apps, your techs can open their entire routes into GoogleMaps), with result that a webpage such as the following shows, and within but a second or so:
This release brings the capability into ServiceDesk itself.
Improved Route Treatment:
A longstanding feature in the DispatchMap is the ability to export the tech's route (essentially the list of addresses he is expected to visit) to a file. This file may be plugged into any mapping program or even into a GPS system that's setup for such import.
Another longstanding feature (associated with the above-described MapPoint integration) is the ability to add beginning and ending waypoints to a route, consisting (at the user's option) of either, in each instance, the office location or the tech's home. This makes it so such routing features may accommodate the full route, starting at whichever location he actually begins at, and terminating at whichever he actually ends at.
With this release, your specification of these add-on beginning and ending waypoints (sometimes I simply call them "end nodes") is no longer limited to MapPoint integration. The specification interface is separated from those specific actions, made independent, and now what you specify there will apply not merely to the MapPoint integration, but also to what's loaded into GoogleMaps (if/when you use that option) and to what's exported to the above-described file.
Another improvement, in regard to what's stuck into an exported file or loaded into MapPoint or GoogleMaps, is if the underlying job is specified as a ShopJob, it will be the office address that's used, and not the consumer's.
Modified Menu and QuickKey Arrangements:
It was impossible for us to add all of the above-described improvements without altering some of the corresponding access methods, as involved in the DispatchMap. Here are changes as made in the DispatchMap's CheatSheet (accessed by right-clicking in any otherwise inoperative DispatchMap space):
The Dispatch-Options menu (as arises when you click on a tech's name at the top of his roster of jobs) is also changed
Instead of explicitly describing here which commands have
changed, we urge you please to just examine the above illustrations.
New "Quiesce" Feature in JobsPerusal Form:
Do you know what TAT is?
It's a nice acronym for turn-around-time. It's the quantity of days between when you receive a job order and when you complete the job. The shorter your average TAT, obviously, the better. This is particularly true if you have one or more large clients that score you on TAT, and dispatch more jobs to you when your TAT is tiny.
This new feature is about helping you trim your TAT to the very smallest possible size. Rather than telling you more here, we'll simply suggest you read the micro-manual we also created to acquaint you with this feature. There's a button on which you can click, for this micro-manual, from within the (Shift-F7) JobsPerusal form:
Or, you may click on
this link.
Further Development on ShopJobs:
I confess.
The new feature (announced three releases back) that exposes within the DispatchMap when an "appointment" is connected to a ShopJob ended up being a little less than perfect. I won't bore you with details explaining why, but the bottom line is that a number of users ended up with a number appointments in the DispatchMap claiming to be ShopJobs, when in fact they were not.
That's fixed with this release.
More importantly, there is also now better integration with
SD-Mobile (also requires updates in SD-Mobile and SD-MobileLink). It will
now be very visible to the tech using Mobile if a particular appointment is
setup as a ShopJob (no more mistakenly driving to the customer's location).
Improved SB-DispatchLink, and Connected Improved Handling on N.E.W. Jobs:
In the SB-DispatchLink program, for a long time, we've been capturing a maximum of two phone numbers, and no email address. It's all we could get, based on the fact ServiceBench's communication protocol did not provide more. Or, rather, their old protocol did not. A while back, however, they came out with a new protocol that added several fields not formerly available (among them, a third telephone number and email address). We needed to re-program the SB-DispatchLink program to use this new protocol. With SB-DispatchLink Ver. 4.5.0, that is done. If the dispatch from ServiceBench has a third telephone number and/or email address (and assuming you've appropriately updated), those will now be plugged in for you.
That's not all.
In regard to work that comes from NEW (and if you're a servicer who does such work), we were formerly handicapped (with that old communication protocol) in regard to our ability to get some extra fields that are "kind-of" needed for NEW claims. Owing to the absence of those fields, NEW claims have involved some extra work for users. Yes, as core philosophy we hate extra work, and are very sorry you had to endure that.
Anyway, the good news is that Ver. 4.5.0 of SB-DispatchLink (using that new communication protocol) is now able to grab the extra fields as needed for NEW claims. It puts these in the ExtraNotes section of the Callsheet it creates. They get transferred from there to the JobRecord when you make one, and when ServiceDesk fills-in the on-screen NARDA for you (preparatory to transmitting a claim), they'll be placed into its needed boxes, such that when you transmit, everything needed should go appropriately to its needed place, just as with claims to OEMs.
In other words (if you did not get the above), there is now no need for you to separately obtain NEW's AuthoNumber, or to re-arrange how any of the NEW-specific fields are setup for you. In fact, it's important that you do not re-arrange them. Leave them just as inserted by the SB-DispatchLink program. Based on that precise arrangement, ServiceDesk's insertion to the on-screen NARDA will be just as it needs to be (in regard to those particular elements, at least) for a successful claim.
If you're a SB-DispatchLink user, please assure you update to 4.5.0 (or newer if present when you get there). Dispatches as received via pre-4.5.0 versions will not grab the extra data, as needed for fully-automated NEW claims.
If you're interested in how the specific "mapping" works, it's like this:
1. SBDL places NEW's CRM/SR # and its Authorization # (embedded within what is esentially narrative text) into the ExtraNotes section of the underlying Callsheet (from whence, of course, it gets transferred to the JobRecord).
2. When SD auto-fills the on-screen NARDA from such a job, it extracts those two numbers (i.e., from the underlying ExtraNotes, and inserts, respectively, into the NARDA's Contract/Service Agreement Number and Special Authorization # fields.
3. Those boxes, in turn (and upon transmitting a claim), insert into SB's Service Agreement Number and Authorization Number fields
4. At the SB end, those two
claims-transmission pockets get translated as needed right back into NEW.
Improved Deletion Management on Dropdown Lists in UIS Form:
The form that manages our UnitInfoSheets (Shift-F12) has long had facility for editing the dropdown lists of item Types, Makes and Selling Dealer. In other words, you may add new listings, change existing ones, or delete existing ones. Typically, that last operation requires a little more than just requesting deletion, because often the item you want to delete already has underlying data sheets claiming it as their applicable Type, Make or Dealer. The system can't permit you to simply delete it, because then any such "sheets" would be missing their references. So, the system formerly put you through a clumsy dialog, instructing you to pick the substitute listing that any such prior dependencies would be switched to. This release fixes the "clumsiness" in that dialog, making the process much more obvious, and with fewer intruding message boxes:
First dialog after deletion request | Graphic as appears after hitting OK |
![]() |
![]() |
New Diagnostic for Network File-Share Issue:
We recently encountered a client who had a very weird problem in his network that severely impacted ServiceDesk performance.
In terms of symptoms, throughout the day users would frequently see the infamous "pink screen" (the one that announces ServiceDesk is waiting to access a file). And, there were often significant other pauses in performance. Bottom line, with these issues, is that one or more stations in the network were lagging for significant periods as they opened and closed files. To help isolate which stations were causing the issue (at least as applicable to the condition as was occurring in this client's network), we developed a diagnostic tool. It proved to be so definitively helpful, we decided to improve it's interface, and incorporate it directly into ServiceDesk:
Selection for new tool is in "Diagnostics" branch off MainMenu | Actual tool is very simple (please note the "About this test" button; it opens a small document that explains details) |
![]() |
![]() |
If you're running with multiple stations and think there's even a chance you may be subject to a similar network issue, we suggest you run this test at each station -- and, in particular, read the document as available via its "About this test" button.
Update on SD-Dealer with
Improved Password Control:
Mary at Landers' Appliance said their operation needed more fine-tuned control on password protections within the SD-Dealer program (prior design had all password requests demanding the Master password). Within ServiceDesk's "Security" form (Shift-F11), you may find three new listings:
The effect of what you do with those, of course, is felt
within the Dealer program itself, and you'll need to update it as well (Ver.
1.0.37) to experience the improvement there.
EmailedDispatchReceiver Now Upgraded in Two Respects:
If you do not know, this is our utility (abbreviated as "EDR") for automating reception of dispatches that are received by email. This morning we release Ver. 4.5.0 of that utility, featuring these major improvements:
1. Integration with the Rossware Direct-Mail Agent:
If you've been reading here, you know that, since introducing our new, direct-mail option, we've gradually increased the scope of Rossware office applications that offer it. Just a month or so ago, we filled-in the roster to include all such applications that send mail. This left out our EDR, for its use of emails is not sending; it's receiving, and that's a very different function.
Regardless, we have now added the direct-mail option there. We think, in fact, it will be particularly useful there, because integration with the standard Windows Mail Client, for receiving purposes, has become increasingly problematic in recent years. Our direct-mail agent promises, in contrast, to be completely problem- and hassle-free.
If you're an EDR user, we strongly urge you to update, and switch to use of the direct-mail agent. There are some particular things you need to know about the transition. They are covered in a newly-added section of the Rossware Email-Users Handbook. Look for Section F in Chapter 3, beginning at the bottom of Page 12.
2. Warrantech Added to Roster of Companies Whose Dispatches May be Parsed:
The heading speaks pretty much for itself. FYI, the roster of dispatch formats the EDR is prepared to parse now include: Custom Answering Service format, American Home Shield, National Electronic Warranty, Fidelity National Home Warranty, Old Republic, PC Richard and (with this release) Warrantech. The latter is also offered (with this release of ServiceDesk) in the QuickEntryTemplate's list of company Types (something you'll need for perfect integration with Warrantech dispatches via the EDR).
Another "Who Done It?" Log, and Related Improvements:
One of the improvements announced in the last-prior release concerned a new underlying log the system maintains. Its a log that typically you'd have no interaction with. But if, after the fact, you wanted to do some investigation seeking to determine who looked up (or changed) part numbers as involved in special-order parts, it's there for you. In announcing that feature, I volunteered that, having built the machinery for that log, it would be relatively easy for us to add logs into other processes, and I invited requests.
The first request came fast.
We have now added a second underlying log. This one will have entries indicating changes as made in the SalesJournal, FundsJournal and A/R records. As with the log prior announced, there is one file where entries as made during the course of a day get entered, and then a long-term file. For this new log, the files are called SlsAndFndsEdits.txt and SlsAndFndsEdits_Archv.txt, respectively.
Since it appears we're going to end up with a whole set
of such log files, we also deemed it best to make, and start placing them
into, their own folder. Thus, instead of using the common \sd\netdata
folder; henceforth, these files will be placed (and used within) a new subfolder
called \sd\LogFiles. Please look for them there.
ShopJobs now Show as such in DispatchMap:
Not far back (see Ver. 4.3.62 entry from 4/18/10) we vastly improved our method for designating those particular jobs that involve in-shop (as opposed to in-field) work. Since then, we've made occasional additions to the operations where ServiceDesk appropriately distinguishes between ShopJobs versus not. This is a related such improvement.
Specifically, someone pointed out that you should be able to readily distinguish, within the DispatchMap, between references to appointments that involve in-shop work, versus those that do not. And, if you're wondering, yes, many operations do schedule in-shop work. For those operations that lack a dedicated, in-shop technician, it's often found that scheduling the work is the only way to get it done.
Based on this improvement, you'll now see ready visual, within-DispatchMap distinctions, as per above.
"Who Done It?" Log Now Available for PartsProcess PartNumber Work:
We heard from a particular client they'd just lost a a thousand bucks based on having ordered a wrong part (someone looked up the part number wrong, and the item was not returnable) from Viking.
Oooouuuuucccchhh!
Understandably, this client wanted the ability to determine precisely who had actually done the lookup on the part number, and who may have edited it thereafter (if, in fact, anyone had). As all seasoned users know, a wide variety of events are automatically documented in the narrative history as applicable to any underlying JobRecord. The kind of event as we're discussing here could, in theory, also be placed there, but as a matter of general strategy we want maintain that narrative in a form that reads well (and easily) as a broad overview of major events, and without so much excessive detail as to defeat that as its purpose. Thus, we needed such historical documentation elsewhere.
Enter the "Log" file. From this release forward, ServiceDesk will write to a file (called PartsProcessWorkLog.txt and located in the \sd\netdata folder on your server) each time any user creates or edits a part number in the PartsProcess system. Each entry will indicate the operator involved, date and time of the event, and precisely what the operator did. At the conclusion of each day, entries in this file will be moved to a more permanent file (PartsProcessWorkLog_Archv.txt, also located in the same \sd\netdata folder on your server).
Based on the above, if you need to find out after the fact who specifically is responsible for having provided (or changed) particular part numbers that were involved in the PartsProcess system, you should be able to easily determine the answer by looking in one of the above-described files (the first one if you're looking for actions that occurred in the current day, the second if looking for actions more in the past).
Having created the machinery for this particular log, we
invite you to let us know of operational areas where you think there'd be a
significant reward for creating similar logs. The way we've structured the
machinery, there is almost zero overhead involved, as cost in such logging
efforts.
"Default-To-Definite" (on Appointment-Assignments) Now Available on a Per-Tech Basis:
This addition was prompted by a call from JD at Guinco Service in Texas. That operation has some techs working in remote regions, and as JD in the office pre-screens jobs he'll often order parts before the tech ever goes out. Pointedly, he has the vendor ship said parts directly to the particular tech -- a factor that, obviously, makes it rather important that when an appointment is created for that tech, its assignment status be set as "Definite," as opposed to "Tentative."
To accommodate this kind of need, you'll now see a new settings area within any tech's Profile sheet, as displays when you click on his name within the TechRoster section of the Settings form:
At least with benefit of description as above-provided, I believe meanings in these new options are obvious. The default selection ("never") leaves functions the same as always. It's only be selecting another option that you'll notice any change in operation.
In the title of this entry, you'll notice, when referring to this new default-setting option, we're ballyhooing the fact it can be done on a "per-tech" basis. The reason for this specific "ballyhoo" is because (and we need to explain it here for full context), a couple of years back (see Ver. 4.3.40 entry from 12/10/09, below) we added on option where, from the Create-Job/Sale form, you can change the default as applies in all instances (i.e., across-the-board). That old (much more of a "blunt knife") option still persists. And it's true, obviously, that If you did have your default set to "Definite" via that old/broad method, any new-option setting via individual techs would be superfluous.
New "Email" Search in Current-JobRecords Form:
Credit for this one goes to Krystle at Folsom Lake Appliance, in California. Krystle was sometimes getting email replies from customers, triggered by them (and generally containing specific inquiries) on the basis of emailed tickets as generated via SD-Mobile. The replies did not contain the originally attached ticket, and it's that ticket (in the context of these emails) that would contain information disclosing who the customer is. Absent knowing who the inquiring customer was, it was difficult for Krystle to respond. Indeed, her only basis for identification in this context was the customer's email address.
In regard to such email addresses, ServiceDesk of course has fields to track them very nicely. However, it's often the case that you do not have the customer's email address prior to sending the tech out. In such a case (and assuming he's using SD-Mobile, and using e-tickets within SD-Mobile), he will acquire the customer's email address in-the-field, as a pre-requisite to sending the e-ticket. This email is then automatically inserted back into the JobRecord, via operations of the SD-MobileLink program.
So, in theory, when Krystle receives the customer's email reply, she should be able to find the JobRecord in ServiceDesk that contains the sender's email address. That will then be the correct customer. Problem is, though email addresses have in general been fully searchable in ServiceDesk, the ability has depended solely on the CstmrDbase Index set, which is typically updated once each night. Thus, if the email had just barely/same-day been obtained (via the tech's getting it for sake of sending the e-ticket), that email address would not yet be discoverable via the long-standing search method. That's why we added a new option to the record-by-record searches, as offered from within the F7 form:
segment from the Current-JobRecords form showing old search options at left |
![]() |
segment from now-revised form showing search options with new addition |
![]() |
As intimated, this new item is one of the set of searches that does not depend on the once-per-night-updated Index set, and thus it can locate an applicable JobRecord on basis of email address even if that address was only added in the current day. In regard to all these searches, please always bear in mind that you are permitted to type only a portion of the search target. Often we see people thinking they have to type the entire thing. That's too much work.
Other:
As is the case with most every release, this one too contains
improvements you should manage to enjoy without needing to first learn of their
existence, via reading here. In general, we don't announce such matters
here, as there is little need. But some matters are almost the opposite,
in that you might think something is wrong, absent an explanation here.
One is as suggested by Adam at Fred's Appliance. As you open a current
JobRecord, the history box will now automatically scroll down (if needed) to
show the bottom/most-recent entries. Please don't think this is a
malfunction. It is intended.
All Features in CyberOffice
Now Functional:
Yes, this one gets a much bigger announcement-heading than most, because it truly is BIG NEWS.
It was some four years ago when we introduced our CyberOffice suite of functions, which involve Rossware-provided plug-in interfaces for your website, combined in several instances with emailed hotlinks. From almost the get-go, we envisioned six core elements in the system: (1) initial online booking of jobs by a customers who browse to your website; (2) online scheduling of first visit on basis of hotlink-equipped email (e.g., you get an order from a third-party for the service and email the location-party with a hotlink to schedule); (3) re-booking appointments after parts arrive; (4) confirming appointments on the day or evening prior; (5) online job-status checking by customers; and (6) online technician tracking by customers.
Scenarios 1 through 4 (as above-listed) were working with our very first roll-out of CyberOffice. We'd intended to add scenarios 5 and 6 soon after, but complications with our online programmer and other priorities intervened. Of course, we did not forget -- and, though later than expected, we are now very pleased and proud to announce that our full CyberOffice vision is now deployed and ready for your use, enjoyment and profit. Scenarios 5 and 6 have been added, and they are beautiful.
In fact, Job-Status checking has been available for about two months, and we have just now opened Tech-Tracking to general use. Here is a comment received after our first beta user had been using the feature for just four days:
"Glade, we started using the technician tracking tool
this week and we already have had 119 people visit this page!!! We have
also had several compliments from customers who have used this tool. I
figured you might like to hear.
Yes, I indeed do love to hear such good news, and I encourage the rest of you to make haste in the effort to likewise benefit via the implementation of these great new features.
For more detailed information, we invite you to consult resources. The first is our CyberOffice Handbook. Second (especially if you are not already familiar with kinds of interfaces that CyberOffice offers your customers) is the CyberOffice section on our website.
This particular release of ServiceDesk is especially pertinent to announcing such new capabilities in CyberOffice, by the way, because it includes an internal enhancement to fully accommodate the last fundamental element. Specifically, when emailing the customer with a request to confirm the next day's appointment, it now uploads a couple of added data elements. It's on the basis of these that, when the customer confirms, the SD-CyberLink program is then able to email the customer a follow-up. Essentially, that follow-up says:
"Thank you for confirming . . . and, by the way, if you are curious how your tech is running tomorrow, click on this link [link actually provided in genuine email]. You'll see progress in his route on the way to you."
The actual tracking page, the user will see, looks something like this:
Of course, the actual list
and details will vary according to the actual situation.
Rossware Direct-Mail-Agent Now in SD-CyberLink:
Simultaneous with the above-announced release of ServiceDesk, we are also releasing Ver. 4.5.0 of the SD-CyberLink program. Besides itself accommodating the above-described email response when a customer confirms, it also now adds integration with the Rossware-Direct Email Agent.
This is the alternate emailing system that we added several months ago as an option in SD-MobileLink, after that into ServiceDesk itself for non-user-reviewed emails, and just recently (two releases back) we enhanced its implementation to accommodate user-reviewed, compose-window-needed emails.
To review, this facility allows emails to be sent using solely Rossware programming, and without reliance on the Windows mail client. It thereby circumvents all the frustrations that were in some instances associated with using the Windows mail client. Much as in the SD-MobileLink program, the new SD-CyberLink features an "Email Setup" button on which you may click to specify your preference to use the Rossware Direct-Mail-Agent, in preference to the default Windows client.
Based on feedback from those who've switched to using the the
direct-mail agent, we can certify it is a great advancement over using the
standard Windows mail client.
New Method/Option for Ordering Inventory/Stock Replenishment:
The inventory system has long offered three methods via which to order stock replenishment. In the F10 form, you may choose to order on the basis of: (1) deficiencies (i.e., where stocked quantities have fallen below planned minimums; (2) recent usage (i.e., simply re-fill based on what was used in a recent/defined period; or (3) simply by picking from the general stock plan the particular items you want to order.
Our new option concerns what is actually an enhancement to the second method. It's designed to fulfill a purpose as revealed by user who does a lot of its work for AHS and NEW, under accounts that require ordering all replacement parts via their own particularly-authorized avenues. To further complicate, this company stocks its trucks very well, and on a high proportion of its jobs (as performed for these clients) the tech uses a part directly from stock. Typically, the particular parts as used from stock was not prior-acquired via the authorized channel for the underlying client -- which means, to effectively acquire payment for the part as used, the company must order its replenishment on that part (i.e., its replenishment back into stock) via the client's particularly authorized channel. This complicates the stock-replenishment scenario vastly, because in general (and until now) it's been designed with the assumption that stock replenishment will be ordered from the vendor who happens at the time to be most "convenient" in terms of pricing and similar factors. Now, regarding particular items as used, replenishment on those particular items must come from particular vendors, and with the order including, too, provision of the underlying client's SWO Number as attached to job on which the prior part was used.
In sum, this client has a need -- in regard to re-stocking inventory -- making a situation that very much resembles special-ordering parts, yet the situation nevertheless involves replenishing stocked inventory, and its after job-completion, rather than during the course of it. In a nutshell, it's a "hybrid" situation: not quite special-order parts, and not just stock inventory, either.
Our solution of the moment is what this new feature is about. Again, it's an enhancement on the prior-existing method for ordering stock replenishment on the basis of items recently used. If you select that option in the F10 form now (i.e., after this update; the series of keystroke-shortcuts to get there is F10, "O", then "R"), you'll see a new sub-option:
While the prior sub-options are designed to print or fax an
order request for your vendor, the new one (as its wording implies) creates a
file that may be opened in a spreadsheet, and this contains added fields that
allow you to see who was the HighVolumeClient (if any) in regard to the prior
parts as used, and as connected with each item that now needs ordered for
re-stock. Plus there is a fields for the applicable client's SWO Number on
the job where used, and for which tech used the part (and hence, presumably
needs re-stocked). Our thinking is you can use the spreadsheet to
determine which parts you have to go through AHS to replenish, which you must go
through NEW, etc. The additional information allows you to frame your
orders with needed underlying SWO Numbers, etc. We think, with creative
use of the spreadsheet machinery (particularly if you're a bit adept in using
Excel or similar), you can likely make this work very well.
Review-First-and-Compose, Direct-Send Emails:
Many readers know that, historically, Rossware systems have "farmed-out" email functions. Rather than handling them directly in other words, they've "called" on Windows to perform wanted email tasks. Windows, in turn, calls on whatever email program is installed and setup as default, if any.
This is precisely how Microsoft has long intended that applications should manage their email-related functions, and in general it works, albeit with occasional frustrations as encountered within particular installations (in other words, you may or may not be fine with that scheme, depending on your setup).
In the effort to once and for all overcome all potential obstacles, last year we introduced a direct-send option. When using this method, Rossware systems perform email tasks directly, using their own mechanisms, and without calling on the Windows Mail Client in any manner. It was first introduced in the SD-MobileLink program, then added to ServiceDesk itself with Rel. 4.4.93 (you may search below to find that release announcement).
At that point, however, there was a limitation. The direct-send method only worked for emails that were sent-off for you directly, behind-the-scenes, and without user-first review. In other words, it did not work for those emails that ServiceDesk opens for you first, in a compose Window, for you to review, perhaps add your own text, and then send. This limitation was because we simply had no compose window of our own, and thus had to refer you to the Windows Mail Client, for use of its compose window.
That is changed with this release.
We have now created our own, ServiceDesk Compose-Email Window, which will be applicable if you opt in the Email Setup form to use the Direct method. Here is what it looks like:
With this addition, you can now totally abandon use of the
Windows Mail Client for all emailing as associated with ServiceDesk. It's
quite flexible. You can even include electronic signatures. All
details are in an also-revised Email Handbook, accessible via button from within
ServiceDesk's Email Setup form, or from
this link.
A Series of Improvements in the New "PartsPick" On-Screen Management Window:
You might notice there have been five releases since the last prior (just below) announcement here. These have included been many small, incremental improvements (and in multiple areas). In particular regard to the new PartsPick interface, experience disclosed certain initial weaknesses (in particular, circumstances where the system might have indicated a potential need for a part to be returned by a tech, but did not), that have now each been addressed. Additionally, Adam Butcher pointed out that it would be nice to see the Bin/Hold Location of a part, right within the interface. That now occurs. Assuming such a field is applicable, as you float your mousepointer over any parts-listed item,
Finally! A "PartsPick" On-Screen Management Window:
For those of you who attended Glade Ross's class at the ASTI convention, this is the feature Steve Merriam has been seeking for three long years (the one in connection with which he told the class: "Don't hold your breath!").
I do apologize, Steve (and likewise to everyone else who should have been enjoying the benefits of this kind of tool) that it's taken so long. I have two excuses. First, it really was a very large project. Second, it truly needed as foundation the kind of improvements I've made, in underlying structure, during the past half year or so (see the many, many entries below regarding that series of improvements).
This new interface can be accessed via the Main Menu (under the Parts Management heading), as follows:
Or, as you can see via the menu-item listing itself, the QuickKey shortcut is Ctrl-Shift/F8.
The basic idea in this new interface is it gives you a single location to see all parts that need assembled for going out with a particular tech for a particular day's work, and to indicate by simple clicking action if in fact you're moving each such item from office to the tech. It further provides a basis, within the same interface, to see what should be coming back from the tech, and to likewise indicate via single click if in fact such items came back.
Here's what it looks like:
We believe that overall this brand new interface is a huge -- nea massive -- improvement over what SD systems prior afforded in regard to these particular processes. In fact, we likely should increase the cost of our support in exchange for bringing such a huge improvement to you. Nah. Just kidding.
Seriously, there's a real and serious reason why Steve Merriam has campaigned so assiduously for this feature. He had the vision, way back, realizing what a value it could have. And, now, his vision is realized. Please be sure you take advantage of it.
To use the new interface -- we think -- will be fairly
self-explanatory. There are a plethora of tooltips within it, if you just
float your mousepointer over various objects (we urge you to do this, as you'll
learn things as you do). There are links and cross-links to virtually
anything your heart might desire. I'll shortly be adding a section in the
manual describing more specifically how all the details work, but I'll bet most
of you can figure it out regardless. I'll place a new entry here
indicating when the manual revision is ready.
A PartsProcess, Non-Usage Analysis:
A couple of months ago, we introduced mechanisms via which techs are required, if they do not end up using a special-ordered part, to indicate the specific reason why not (see, e.g., notes accompanying Rel. 4.4.88). With that new element of data having since been in a state of being constantly generated, a few users got to thinking they'd like to see an at-a-glance, across the board analysis of which techs were ordering parts without using them, at what rates for each, and for what reasons.
We now have a report to provide that.
Much like its cousin, the Usage Analysis report, this new report is accessed from the archived-PartsProcess form (Ctrl-F8):
Simply pick the new option, follow the prompts, and in a moment you'll be looking at the new analysis.
One note: Just like the Sales Tax Liability Report as
just-prior-to-this introduced, this one also requires Excel or similar
spreadsheet program for good viewing. Please be sure to open the results
within such a viewer.
Finally, a Compiled, Sales Tax Liability Report:
Another area we've been a little slow with ServiceDesk is in management of sales tax liabilities. This likely stems from the fact that in SD's germinating office there was but a single tax jurisdiction (and corresponding single tax-rate scheme) to worry about. For this, a simple SD-management structure was totally adequate. Most other users have not had it so easy. For the sake of our very first new users, we made an option where, in the Settings form, you can indicate that you have varying rates depending on location, but until Rel. 4.4.5 there was no provision for you to explicitly inform ServiceDesk as to what rate existed in each particular locale (instead, ServiceDesk simply relied on the amounts as filled in to any ticket by the tech at the location).
That provision -- for jurisdiction specific rates -- was added just over two years ago. However, we left a significant hole. While ServiceDesk could now know the rate that should properly apply depending on job location, it did not give you any kind of compiled report informing you of what your accrued liabilities were for each jurisdiction. Instead, the interim expectation was that you'd export the underlying and nearly raw data (via Sales Summary add-on in the F11 form), then manipulate in a spreadsheet to self-calculate your various liabilities.
This release fills that hole.
Specifically, if you first run a Sales Summary report in the F11 form (for any period of interest), then click on its "Export with Extended Data" button, you'll see the options as then presented have gone . . .
from this: | to this: |
![]() |
![]() |
The newly-added option will create a compiled report detailing your total tax obligations in each jurisdiction (as per specification in your TaxRatesFile, which is the provision we added a couple of years ago). For instructions on how that file is setup, you can click on the little button as provided in your Settings form:
The compiled report is too big to illustrate here. But we think you'll like it. One thing you'll notice is that, unlike all our other compiled reports, this one is deliberately made to display within a spreadsheet program, such as Excel or similar. If you attempt to display it otherwise, you're not likely to get good results.
Another note: though the compiled report is designed to give
you segregated liabilities among multiple jurisdictions, even a company that
reports to a single jurisdiction might find it useful. If yours is such an
operation and you'd like to try the report, you'll need to create that
TaxRatesFile first. Just because you have but a single jurisdiction,
doesn't mean you cannot create the file regardless.
All Moderate-Level Requests Fulfilled (as per List of Items Requested in My ASTI Class):
Last Tuesday in San Diego, we had a fantastic set of three classes at the United Servicer's Association annual convention (aka the Appliance Service Training Institute, or ASTI). In my own class (and as is now tradition), discussion brought out the need for a number of improvements. Michael Basich (of Michaelson's Appliance Repair of Tampa) kindly tallied 16 such requests, and emailed me the list. Though I only got back on Friday afternoon, I've already mostly killed the list. Here is my general report:
Out of 16 items tallied, 4 involved supplementary products rather than ServiceDesk (and I still must get to those). One involves a very large project I intend to conquer soon. Two were for fixes that, upon going to address, I found ServiceDesk was already behaving exactly in the manner requested (read near bottom of this entry for details on those). This leaves nine items, total, that I was able to conquer this weekend, as now available in this (Monday morning's) release:
1. DTR-Viewer Now Functional Even for TimeCards Not Done via SD-Mobile:
In the class, I always show-off new features as added since the prior class a year earlier. When I showed the new DTR-Viewer (see entry as pertaining to Rel. 4.4.68), someone pointed out that the Viewer works only for TimeCards as compiled by a tech working in SD-Mobile, and not for someone that does his TimeCard punches via ServiceDesk itself. I'd not intended such a limitation when I created the feature, and was surprised by the report. On review, I found the Viewer's disability in regard to within-ServiceDesk created TimeCards was the unintended consequence of a coding variation, which has now been addressed.
2. Auto-Add to JobRecord Historical Narratives When User Changes Tech Assigned to Appointment:
Suppose you're in the DispatchMap and change the tech assigned to an appointment. I've never thought this kind of event should be automatically documented to the JobRecord's history, because to me it's not particularly significant as concerns performance on the job. But many have asked for it, and in the class I was persuaded to at least make it an option. So now, if you go to your Settings form (Ctrl-F11), you'll see a new checkbox where you can set to activate this new offering:
Applicable section as prior offered | Now with new option |
![]() |
![]() |
Obviously, if you go to your Settings form and check that new option, you should see these new historical narratives added, any time someone changes the tech as assigned to an appointment.
3. DispatchMap Auto-Popups Moved to Right:
We also discussed the DispatchMap's auto-popup feature, as added with Rel. 4.4.53. During discussion it was agreed the popup would be better if moved to the right of the underlying text:
Showing popup as traditionally prior located | As now moved to the right |
![]() |
![]() |
4. Add Password-Protection Security for Edits in the MasterPartsPlan:
I was surprised to learn that, somehow, I'd evidently neglected add an option to enable the above-indicated protection. It's there now. Just open your Security-Actions form (Shift-F11), and click on the Actions radio button. If you sort on the Action/Process column, you'll see there already were, in fact, several categories of optional protection as applicable to the MasterPartsPlan, but only now (with addition of the highlighted item below) is there one to optionally protect against editing, there, in general.
You'll need to toggle the password protection on this item to True, if you want it to take effect (default is False).
5. Prevent ServiceDesk from Emailing an Appointment Confirmation Reminder When the Underlying Item is Designated as a ShopJob:
The above pretty much speaks for itself.
6. Allow for Deletion of Daughter Bands as Added to Archived-PartsProcess Records:
Ditto.
7. Make a More Simple QuickKey Access for the SD-Rolodex:
For obvious reasons, I'm always reluctant to change QuickKey or Mouse action users have become accustomed to. However, since adding the SD-Rolodex feature about a year ago, I've often felt it deserves its own direct F-Key access (i.e., without combination with a modifier key). For a form that a user wants to so frequently bring up, Shift-F3 (the action to-date) seemed way too difficult. At the same time, I did not think the SalesViewer form needed access all that often, and so did not think it really deserved F4 sweet spot it's always (until this date) enjoyed. Given the above, I put it to the class, asking how they'd feel if I swapped the two. They voted in favor, so now it's a reality. F4 gives you the SD-Rolodex. Shift-F3 gives you the SalesViewer form.
8. Flag JobRecords in ServiceDesk if/when Connected to an SDRB Account:
SDRB stands for SD-RevenueBuilder. If you do not know, it's a supplemental program designed to assist you in managing your own service contracts and/or maintenance agreements, and to integrate with ServiceDesk while doing so. More than a year ago, someone mentioned that a tech in the SD-Mobile should have a visual indicator if the property that he's working at is subject to an SDRB account. We added a visual indicator there, but for some reason did not think of doing the same within ServiceDesk itself. That oversight has now been corrected. Specifically, any current JobRecord that's subject to a pending SDRB contract at the address in question will show with a visual indicator as follows:
This indicator will appear next to whichever section (Paying-Party or Go-To) as has the matching address. As another benefit, you can simply click on the reference to immediately link to the SDRB account in question.
9. Archived-JobRecords Now Packed More Loosely:
In the interest of using data space efficiently, ServiceDesk packs JobRecords somewhat tightly when moving them to the Archive. Specifically, for the last two or three years, its been leaving just 250 spaces between each record -- 250 spaces where characters can be added, if, after the record is archived, you find yourself wanting to add new text (in any context aside from AfterNotes, which don't count because they are stored separately). In the class we talked about how sometimes this is less room than needed for some purposes. Since storage space is so much more liberally available today, we decided it was time to be less stingy. Now, JobRecords will be packed to the archive with 500 extra spaces allotted for each.
As mentioned, there were two items in the list that, upon going to address, I found ServiceDesk was already doing precisely as requested. At least, it sure did so far as my testing is concerned. It's possible users have found contexts where it's otherwise, and I describe the items here so that, if so, hopefully such users can tell me how to replicate whatever failure they are experiencing:
10. Exclude POS Transactions from the Profitability Report:
With release of Ver. 4.4.72 we added a new Profitability Report. Someone in the class said the report was including values of parts sales as conducted across-the-counter -- which would not make good sense, since the report is intended to analyze profitability of service operations. On reviewing, though, I found my program code was already very deliberately written to exclude POS transactions. If anyone truly encounters any experience to suggest otherwise, please let me know.
11. When Scheduling a ShopJob, There Should be No Dialog Complaining about Absence of Grid Coordinates:
Someone said they got this dialog. I found my program code specifically designed to prevent its occurrence in the ShopJob situation, and my tests show it working. Again, if you can find a scenario where it's otherwise, please let me know.
To remind, there were 16 items from the class total.
Another four (work still pending) involve programs other than ServiceDesk.
The remaining one is a big project, one which I happen to have actually been
working toward for three years now. I'm hoping to have it out soon.
New Accommodation for Techs Without Inventory:
In its standard default mode, ServiceDesk assumes each tech as listed in its TechRoster is an inventory location (or, more properly, that he drives a truck that's an inventory location). For a good share of companies, this assumption works great. For those companies where the assumption fails, we have long had an option whereby you can turn off that default by instead explicitly listing your inventory locations.
That's the background for our new feature. It arose when we got a call from a new client whose techs (or, rather, some of them) own and use their own inventory. When items are used by these techs, it's the office's duty to "reimburse" them by replacing the part they've used. But the office is not otherwise tracking what's on these techs' trucks, so how can it easily manage this replacement process?
My first answer was to suggest using the re-stock method (in the F10 InventoryControl form) that reviews usages and generates a re-stock list on that basis (i.e., rather than comparing remaining stock to minimums, as is the more typical method). But there was a catch. If the tech attempts to indicate he used a part from stock, and if the system doesn't recognize he has the part (because, obviously, it's not tracking his inventory as all), it's going to balk at the claimed usage. Moreover, if you'll actually be pulling from the office to replace what the tech used, that's from whence the indicated usage must come (so that, in other words, there's an appropriate reduction of stock there).
We have accommodated the above-expressed need via a new option, as below indicated, in the (Ctrl-F1) Settings form:
If you check that box for a particular tech, ServiceDesk then knows to NOT treat him as an inventory location. This works independently of the feature that allows you to explicitly list locations, and in response to the setting here, if in a PVR a tech claims to have used a part from inventory, the system will assume it was actually office inventory he used, rather than seeking to find it within his own (non-existing) inventory.
Behind the scenes (and for the above-described scenario) ServiceDesk will actually be making two simultaneous entries in the Journal of Inventory Movements. One moves the item from the Office inventory to the tech in question. The other, instantaneously thereafter, moves it from the tech to sale on the job in question.
While instigated by that new client (and to accommodate the need to replace parts as used by technicians who carry their own inventory), this solution should also be effective for shop techs -- who typically do not have their own inventory and are regularly pulling from office stock regardless. Either way, we think you'll find it a great solution.
BTW, the MobileLink program has also been modified to recognize and appropriately respond to this new option (so that tech's working via the Mobile interface, and designated as having no inventory, can likewise benefit). You will need to be updated to Ver. 1.4.46 of MobileLink to have the benefit there.
New Usages Report/Export:
For quite a long while we've had a report in the archived-JobRecords form that's designed to provide you with analysis and data regarding your frequency of use for all parts, both stocking and special order. Turns out some folks have wanted to do some kinds of analysis that do not exist in the report directly, and wanted more item-by-item type raw data than the existing report provided. So, we created a new option:
If you're interested in more extended analysis in this area,
check it out.
Interim Search Results within the Archived-PartsProcess Form:
When a little while back we improved the method of displaying search results in this context (making the interface more one of paging up and down), we produced an unintended downside. Turns out the old and less sophisticated interface had one benefit. If your data set is so large so there's a long delay before the entire file is searched, and if your search target finds matches within the data so infrequently that it takes a significant wait before a page is filled, it turns out you could wait quite a while before seeing any search results.
This release addresses that. Now, the system will show interim search results just as it did before (but with a background color of pink, to make it visually apparent that you're not yet seeing a formatted page). If you see what you're seeking and want to terminate the search, just strike Enter on your keyboard.
Many Other Improvements:
You might notice it's been five releases since the last-prior
announced one. Sometimes, I go through a stage where I'm very busy making
a large series of small, behind-the-scenes improvements, but with none so
noticeable to the typical user as to really warrant description here.
That's been largely the case during the last 30 days, encompassing the prior
four releases.
Direct Emailing -- a Beautiful Bypass Around the Windows Mail Client:
Several Rossware applications use email (I'm referring to normal, internet/based mail here, rather than to ServiceDesk's internal "SD-Mail" system). Always, Rossware email access has been via what's called the Windows Mail Client -- which is simply the email program you have installed, at the station in question, to manage emails, and which is designated within Windows as its "default" email program.
To put the above another way, Rossware programs have never directly performed email-related tasks. Instead, they hand the task off to Windows, which (in turn) hands it off to the separate email program (e.g., Outlook Express, Outlook, Eudora, etc.) -- if any -- that you have setup for the purpose.
Given the above, if you have not appropriately setup such another program at any particular station, Rossware programs cannot perform email tasks at that station. Even then, there may be issues, because (and for a number of reasons) such other programs may refuse to cooperate as perfectly as wanted.
This release provides a direct bypass around any/all such issues. Now ServiceDesk can perform email tasks directly, without relying on the Windows Mail Client. Or, if you prefer, you may continue in the traditional fashion.
To invoke (or even just explore) the new option, click on File Functions within the ServiceDesk MainMenu, and pick the new menu item now listed there:
In response, you'll see the following new form:
This is where you can change from the default email mode
(i.e., using the Windows Mail Client) to using the direct method instead.
Please also note there is a large button you can click, which opens a
handbook that explains greater detail.
More Enhancements -- Still -- in the PartsProcess System:
1. Added still another search-and-report criteria in our "To-the-Grave" management/monitoring system (as available from the Ctrl-F8 archived-PartsProcess form). This is for items that have been sent back to the vendor, and which are "Past-Due" for credit being received. Since this increased the quantity of such criteria to nine, we also added some categorization to the relevant menu sections, so as to improve ease of review/choice:
Prior options as available just prior to this release | With new option added, plus improved organization |
![]() |
![]() |
We think it's an improvement not only operationally, but visually too.
2. Improved the new "Manage-Return" daughter-band creation (see #4 in entry for 4.4.89) with the following dialog:
Old | New |
![]() |
![]() |
The middle option, from the old, has been replaced with two options in the new. The effect is self-explanatory, if you simply read the text.
3. Reconfigured supplementary filtering, in the archived context, to encompass both the view/search and create-document modes of managing items "to-the-grave"
relevant section from prior MainMenu section | from Just-Improved |
![]() |
![]() |
4. Re-Allowed type-in targets for all filtering modes.
This one requires some background. As the first item
under Rel. 4.4.89, you'll see where we announced "much enhanced filtering."
In general, it was much enhanced. However, with the transition to
a more modern interface we unwittingly gave up something. In the older
methods, you'd typically be typing in your filtering targets. Under the
new, we only made ability for you to pick from dropdowns (such as, for example,
illustrated under item #3 above). This robbed you of the flexibility
that's involved in entering a target that does not exist in the dropdown.
That's fixed with this release. If you want a target that's not in the
dropdown, just type it into the dropdown box.
Another Enhancement in the PartsProcess System:
I'm sure we'll get though this series of improvements some day, but it turns out we're not actually done yet. The latest improvement involves how ServiceDesk presents search results in the archived PartsProcess form (Ctrl-F8). Since it's showing you search results, and since the search direction has historically been programmed to begin at the bottom/most-recent position in the data, the traditional method of presentation has been as follows:
As the system reads in the file and finds each match to your search target, it displays the first match at top of the form. The second match displays in the next line position, and so on, until a page of matches is filled (assuming there are enough matches to fill a page or more). At that point the search pauses, giving you a chance to examine the page. With press of any key, the search resumes, potentially filling a new page, and so on. This method had several disadvantages if you're doing intensive work in the archive -- in particular, the kind of work that our prior recent improvements have now made practical.
Given that we're now doing serious work in the archive, we realized there is now serious need for a better method of reviewing searched archive results. This release provides that.
Most importantly, you can now use PgUp and PgDn on your keyboard to move up and down within search results (i.e., it's no longer limited to pressing any key for the sake of moving up only).
Additionally, under the old method results were always inverted in comparison to the order items were archived (i.e., newer items were at the top of any display, progressing to older toward the bottom). This was backward from how the items actually fit in the file, and as you progressed to the next page (presenting successively older items), it resulted in repeated inversions between the order in which the pages came and the order of specific items as presented on each page. With the present improvement, each page shows its member items in exactly the correct sequence, regardless of whether the page is reached by perusing in PgUp or PgDn mode.
Improved Claims Formulation for LG:
We recently learned of some particular fields as involved in
LG claims that could be better formulated to achieve successful processing.
This applies particularly on the CE side. That applicable TranslationTip-ToolTips
have been revised to guide you regarding the improved treatments.
Continuing/Further Enhancements in the PartsProcess System:
We must thank David and Paul Manning, at Sharper Electronics in Portland, for this continuing series of improvements. Their intense need, for perfect and complete PartsProcess management, is what's spurred this flurry of activity. Aside from one added report (to tally reasons why ordered parts ended up not being used), I believe this installment fulfills their needs -- and likely almost anyone else's, as well.
1. We now have much-enhanced secondary filtering of items displayed, in both the current PartsProcess form (F8) and for when reviewing items "not-yet-in-the-grave" via the archived PartsProcess form (Ctrl-F8). To properly accommodate these enhancements, there was a need to totally re-do the menu system as applicable in both contexts. It is, indeed, now much modernized. Here's a comparison in the current context:
Old Menu in the F8 form | New Menu in the F8 form |
![]() |
![]() |
The archived context is similarly changed, though in a manner unique to that venue. In lieu of illustrating here, please, just check it live, yourself.
2. Core-return management has been added to the SD-Mobile context. When we first created explicit core-return management back in August, we intended to immediately follow by placing into the Mobile context some corresponding functions. For example, if for any part you've created a core-return daughter band within ServiceDesk, it's logical that if a tech working via Mobile indicates usage on the part, he should immediately be confronted with an extremely strong message informing him that it's a core-return item, and soliciting his affirmation that he has indeed retrieved the old part for return. As it happened, I got sidetracked on other projects and did immediately get this related work done. However, it is done presently.
3. Created a "Resurrection" facility to deal with the situation where you forgot to add a core-return daughter band, and the parent process item was already archived. Just locate the archived item in the archived PartsProcess form (Ctrl-F8), right-click within the right two-thirds of the info-band, then follow the prompts.
4. Created a "New-Daughter-Band-In-Archive"
facility to assist in better tracking of steps as taken in managing a needed
parts return. The general idea is that you can use the various date boxes,
and such, in a manner that parallels what you do in managing a core return
(i.e., document when you requested an RMA, when when you shipped, tracking
number, precisely when credit was received (and on what invoice number), etc. --
all via an added daughter-band that you add for the purpose. To invoke,
begin by using precisely the same click action as described for #3, above, then
just follow the menu in an appropriate alternate fashion.
Still More Enhancements in the PartsProcess System:
In the last release we made a new category for parts disposition: "RA Rqstd" (see Item 4 in the entry below, from 11/30/10). But we did not make a new search category for it. That oversight is now corrected. In fact, while in the course of of adding that as another search criteria, we overhauled the overall organization as involved in those criteria selections. The sequence now has greater logic and clarity:
Just barely old | Now the new, new |
![]() |
![]() |
Also tweaked a few things as connected with the recent add-ons. Example: a user discovered that the "Returned to Vendor and Awaiting Credit" category improperly included items marked with the new "RA Rqstd" designation. That (among other things) has been finessed.
As another improvement, there is a new dropdown via which office persons can insert reasons why a tech did not use a part (see 10/12/10 entry in the SD-Mobile WorkDiary for explanation of how we there created provision for a tech to explain his reason for non-use).
float your mouse for a tooltip reminder | a double-click produces the actual dropdown |
![]() |
![]() |
If you float your mousepointer over the Notes editing box, the
Tooltip will inform you of the method to get the new dropdown (just
double-click). Once you, do the dropdown appears, and all you must do is
select from it.
More Enhancements for the PartsProcess System:
1. We discovered that if you're doing a search function in the archived-PartsProcess form (Ctrl-F10), and if you tried to PgUp or PgDn after reaching the final page of search results, the system erroneously went into an attempted (but not properly-operational) page-change mode. Fixed.
2. Also in the archived-PartsProcess form (Ctrl-F10), added a new search/selection criteria to the "Review Items Not Disposed Of" category.
Old | New |
![]() |
![]() |
More specifically, we took what had been a single category selection (above-left), and split it into two more specific categories (above-right). The above labelling is likely self-explanatory.
3. As another refinement connected with the above-circled category, the system now properly excludes from the result items that are shown as in possession of the office (OF).
4. Added a new category to the that provides potential insertions to the bin-loc/status box.
As is likely obvious, this is used to indicate that you're requested a Return Authorization from your vendor.
5. For Core Returns (current PartsProcess form, F8), added a new display category, as follows:
Again, the function is likely self-explanatory, if you simply look at the above.
6. Also in regard to Core Returns, modified
the applicable filtering to prevent the second category (in this listing as
above shown) from including items where the tech has not yet used the parent
part.
A Fix for "The Best-Laid Plans of Mice and Men":
That above-quoted and familiar phrase is from an 18th century poem by Robert Burns. I'm not normally one to like poetry (actually, never), but when I was thinking about the subject of this entry the indicated phrase entered my mind as seeming apt. The notion the phrase evokes, of course, is that, whether you're a mouse or man, you can lay very grand plans, and yet in spite of all determination and hope, they may nevertheless come to naught. I'll get to that actual happenstance (as regards a couple of schemes within ServiceDesk) in a moment, but first, more about the poem.
Probably like you, I had no idea where that "Best-Laid Plans" phrase came from, so I Googled it, and quickly arrived at http://en.wikipedia.org/wiki/To_a_Mouse. It revealed the origin, and provides full text of the short poem (both original and translated into more modern English). I read the modern translation, and, dang, I like it. It's a really cool poem. Check it out.
Now, to the real topic.
In the last few months, I've made some major improvements in the PartsProcess system's "To-the-Grave" elements of management. Notably, in such regard:
In the archived view of the PartsProcess form (Ctrl-F8), I added the option to visually review items that do not show a complete and final disposition (whether it's use on the job, being returned to the vendor and credit received, etc. Or, you can create an export containing the same information.
In the current view of the PartsProcess form (F8), I added the option to create Core-Return daughter bands, and to visually review each item that contains any such band as may still be pending (i.e., core credit not yet received).
Here is where my rodent-brain scheming went awry.
It turns out that when you add a core-return daughter band to a parent PartsProcess request (pursuing Number 2, above), it prevents the parent from being moved to the archive -- until, of course, the core-return daughter in itself is complete and ready for such movement. This is perfectly fine so far as managing the core is concerned, but throws a wrench into the works of reviewing received items to assure all reach a proper destination (Number 1 above). At least, this is true if you use the new core-return function.
The reason for this frustration is because (and until now) the review-non-fully-disposed-of-items function has been designed to look solely at items in the PartsProcess archive. This formerly made perfect sense, because items received and appropriately priced are automatically moved to the archive, and there they are ready for the indicated type of review. The problem is that the added/new core-return strategy prevents applicable items from being so moved -- for the duration of the time it takes to get the core returned and credit received. In the meantime, there may be unused and un-returned items that are not showing up in the very review where you want to see them.
Hopefully, you can now see how these two schemes collided. We can thank Paul and David Manning at Sharper Electronics for bringing the matter to light (they ploughed up my nest, so to speak).
So, what is the fix?
In a nutshell, the review-non-fully-disposed-of-items function (Number 1 above) will now look in both archived and current PartsProcess locations.
For the export/report option, making the report function additionally look in the current PartsProcess file is a simple, behind-the-scenes change (you'll simply see more stuff, if applicable, in the resulting report).
For the on-screen review mode, it's more complex. The archived view of the PartsProcess form is designed solely to show archived records, and vice versa in regard to the current view of the form -- yet, you need to see results (for the review we're concerned with here) from both sources at once. In theory, we could make a hybridized machinery that would simultaneously show records from both and within a single form view (plus allow editing, etc.), but the mechanisms would be very difficult from a programming perspective. Also, the result might be confusing to the user.
Instead, we've added an option. When, from the archived view of the PartsProcess form you pick the display category "items Received but not disposed of," you'll now have a checkbox option labeled "Include items from current file."
If you proceed with that option checked, the ServiceDesk interface will maximize to use the entirety of your screen. This is to make room for both archived and current views of the PartsProcess form to simultaneously display (and without one covering the other), each in a mode to show you items-not-fully-disposed-of. Thus, you can truly see (and work upon) the entire set of such items at once.
Take that, you unforgiving universe. Perhaps we should
now consider a new title for this section: maybe "Rodent Brain Strikes Back!"
"Hlpng" Expression Added to Appointment Drop-Down:
In the ServiceDesk ScheduleList form (F6), the box as normally used for the customer's name can serve an occasional alternate purpose. If you want to make an entry indicating that a tech will be absent, for example, particular expressions can be used to fit the situation. Historically, there was a quick-key shortcut for inserting these, but about eight months ago we made easy insertion available via a dropdown (see second description accompanying release of Ver. 4.4.55).
Recently, we realized that our new dropdown should have included another special expression:
You can see our new addition (as the fourth/bottom item) in the dropdown illustrated above.
The "Hlpng" expression has been a tool in ServiceDesk for a long, long time. It's used where you're sending a second (or third or fourth) tech to a job, and need to make an appointment entry for that tech. However, you want this entry to be distinguished in a manner that shows the involved tech's role is secondary -- one of merely "helping" the primary tech. It also tells ServiceDesk that, in connection with that particular appointment entry, there should be no expectation of a PostVisitReport, and things of that nature.
The fact is, any of these expressions could always be typed in. However, the dropdown gives you an easier means of insertion, along with assurance that the expression will be inserted with precisely the spelling, as required (vowels eliminated), via which ServiceDesk will recognize the intended operative purpose. In specific regard to the "Hlpng" expression, BTW, you will find it helpful to add (via your own typing) an applicable two-letter abbreviation for the primary tech who's being "helped" (for example, the full resulting text might read "Hlpng DS" where a guy named Dave Somer is the primary tech).
Other:
Yes, if you check the prior release/version number, you'll see
we did two whole releases with no announcements here. Rest assured, there
were indeed improvements -- just none that warranted particular descriptions
here. The more announcement-worthy improvements during this period have
been on the Mobile side (for details, see our
Mobile-WorkDiary).
Date-Picker Type Calendars Added to Some New Locations:
One of our newer users (David Lange from Oak Valley Appliance) doesn't like to type in dates (can't blame him really), and noticed a few places the system could have (but did not) provide a date-picker calendar. We have now added the accommodation to those locations, as follows:
In the UnitInfo form's Purchase Date box:
In the Hibernate form's Sleep Until . . . box:
And, in the PartsProcess form's Date Expected box:
This last context has always had the "date-hence" option (type "3d" for example, and the system inserts a date 3 days in the future), but for some situations the calendar is likely to be easier.
LG-Formatted Parts Order File:
This one is also from David Lange. Turns out (we did not know this), LG evidently has a method via which you can upload a file specifying the items you wish to order -- as the simplified means of creating an order. Since we're always fond of any means for creating labor-saving automation, we quickly created an option to create an order file in LG's format.
The above option is obtained, from the PartsProcess form (F8), by selecting items to order in the standard fashion, then hitting Enter to proceed with the order.
Folder Segmentation Now an Option for Your HLinks Folder:
Some three-plus years ago (see announcement accompanying Rel. 4.3.11) we introduced our Hyperlink feature: the ability to have in-text links in a variety of ServiceDesk venues that reference other objects (picture files, text files, websites, etc.). You can drag and drop and create such links, and a simple double-click on any such link (once it's created) opens the object for you.
In general, the system creates files for the objects as linked to a subfolder of the \sd folder on your server. The subfolder is called HLinks (thus, if ServiceDesk is installed on your server's c: drive, the full path for the folder would be c:\sd\HLinks).
As time has passed, some of our users have accumulated tens of thousands of files within their HLinks folders. Typically, most of these files are images of tickets as created by SD-Mobile. Regardless, when a large a quantity of such files are of images, a potential issue is born. It's because many image viewers (the programs that open such a file and display the image for you) do something behind the scenes, when asked to open a particular file. This "something," evidently, involves surveying all other image files within the same folder. Where there many thousands of them, the opening operation can become rather (perhaps even unbelievably) slow.
With this release of ServiceDesk, you can now create subfolders within your HLinks folder (as many as you like, and named in whatever manner you like), and move some portion of the files into each. If it was us, we'd likely use a strategy such as making a subfolder for each past year (labeled as such), and move all the files as created within that year to that subfolder.
Naturally, even prior to this release you could have created such subfolders, and moved some portion of the file population into each. The difference with this release is that, prior, ServiceDesk would look for a file only within the root level of the HLinks folder. From this release forward, it will look both within the root level, and within immediate subfolders it happens to find there.
Please notice the emphasis, above, on the word "immediate."
ServiceDesk will not look to subfolders of subfolders. If you bury files
in hierarchy that deep, ServiceDesk will not find them.
"Down Boy, Down!" Improved Overbooking Alert Now Tamed:
Two releases back, we described an improvement in how the system looks at availability, via the ZoneScheduling system, to decide whether to warn an operator against overbooking. Specifically, we'd found that if day-portion vacancies (i.e., morning or afternoon) were available for a particular zone/day socket, but not all-day vacancies, the alert would trigger if an operator attempted to schedule an all-day appointment. This didn't seem logical, since all-day appointments are more liberal to internal management than mere day-portion ones, if day-portion slots are available, it stands to reason, a fortiori, that all-day ones should be permitted.
So (and via a significant internal rebuild) we fixed it. Then we got calls. Lots of them.
Turns out the old system had been being liberal in the opposite way (one that, arguably, logic dictates against). Specifically, it had been permitting (without alert) scheduling of day-portion appointments in the presence of available all-day allocations, but absent any applicable day-portion allocation. Our rebuild incidentally fixed this. In other words, via the improvements as made, an operator could no longer schedule for a day portion, absent warning, unless there were unused allocations for that day-portion.
Logical or not, people did not like this "improvement."
So, with this release, the old (arguably less logical) liberality is back.
Regardless, the new and added (more logical) liberality, as added two releases
back, of course endures.
Customizable Text for Emailed Appointment Reminder/Request-for-Confirmation:
For a few years now, ServiceDesk has had the ability to auto-email appointment reminders (and corresponding requests for confirmation) to your customers. It works great, whether configured so the email asks the customer to confirm via email/phone reply, or via on-line interface as part of the CyberOffice system.
A small rough spot, however, has concerned verbiage as used in the email. About a year ago, we received reports that some customers were not taking the request to confirm with sufficient seriousness. In response, we strengthened the language, adding a statement indicating that if a response was not forthcoming, the appointment might not be held open. After that, we received reports that some customers were offended by the "threat." Aside from such difficulties in our own efforts to get the language "just right," there's also the fact you might want to have elements in the language that are particular to your own policies, preferences and situation.
Given such matters, we have now added this email context to the array of those you can customize, according to your own company preference. For details on how, please see the CyberOffice Handbook, beginning in the section that starts (about two-thirds down) on its Page 13.
Aside from allowing you to now completely customize, we have also improved the stock language (with the language having been at first too nice, and then too mean, we believe we may now have stopped the pendulum about right in the middle, where it should be):
Perhaps, with this improved stock language, you may not feel
there is any need to customize. But, at least if you want, customization
is definitely now available.
NSA Export:
NSA is the National Service Alliance, an organization formed by a consortium of leading servicers in the CE industry to perform a package of services that, in some respects is, is similar to those performed by ServiceBench and ServicePower. At any rate, member servicers have the need to regularly upload certain elements of data concerning job status to the NSA server. This new export is meant to facilitate that. It's accessed via the Export Customer Data form (Alt-F3).
Presently, the export is configured to create references solely to jobs that are setup with "COSTCO" or "SONY" as the underlying client (it's possible in the future we'll need to make this client-filter customizable, but for now it's hard-coded). It will also be necessary, at present, for you to manually upload/ftp this file to NSA (we'll create a self-FTPer as our next improvement).
Please also note that, while the dialog asks you to specify a name/path for the main output file, the process will actually build that file, plus two others. NSA wants three files in total: the main one, plus a second that details parts-on-order, and a third that details parts-used. You'll find the added files named similarly to the main one, and in the same folder location.
Improved Zone-Overbooking Alert:
Yesterday it came to my attention you could have the following scenario:
For a particular date and zone, you have slots open for AM and/or slots open for PM, but none allocated for All-Day. A call-taker wants to book a job for all-day. As he attempts to do so, he gets a warning that indicates no slots are available.
The above is thinly rational -- in the very technical sense that, indeed, no specifically-designated all-day slots are available. But, as a matter of practicality, if I have morning or afternoon-specific slots available, I ought to be able to book all-day without the system complaining.
This is, obviously, a really basic matter, and considering how
long the Zone-Scheduling system has been in play it seems pretty shocking that
it never prior came up -- so shocking that when it did come to my attention
yesterday, I felt determined to address it immediately. As part of the
improvement, I rebuilt a great deal of the underlying program code (what with
flowing pipes, and all, it's very complicated stuff) and improved the overall dialog
that results when an overbooking situation exists.
Miscellaneous Fixes, Improvements and Tweaks:
Sometimes, it's just a series of things that are too small and
too numerous to merit individual description, within a venue like this.
That was the case with these releases.
Further Improvements in the "To-Grave" Segment of our "Cradle-to-Grave" Parts Management System:
Back with release of Ver. 4.3.99 (posted 8/31/08, you may peruse below to find), I thought I'd completing programming per the subject as described in this section's heading. As it turns, however, we've periodically learned of need for added improvements. This release introduces four more:
"To-Grave" Improvement #1. Among the "final disposition" checkoff categories we allowed for in Ver. 4.3.99 design, there was one called "RtrnCrdt" -- intended to show, alternatively, either that a part had been returned with expectation that you'd receive credit, or that return credit had actually been received (the choice of which way to use it was up to you). I should have realized at the time this was really a poor design. You need to be able to distinguish between the two modes. To that end, the "RtrnCrdt" choice has now been eliminated. In its place are two options: "RtToVndr" and "CrdtRcvd" (why couldn't I have been that smart from the start?).
Old Dropdown | New Dropdown |
![]() |
![]() |
You should note there is an important distinction between the old "RtrnCrdt" designator, and the pair of new ones. The old one was an in-the-grave categorization. So is one of the new designators ("CrdtRcvd"). The other ("RtToVndr"), however, is not. This latter is considered a still living-in-the-system, still in-process category.
FYI, any old records that have already been recorded with the old designator will stay as such, but from here on out you can use either of the much more descriptive pair (depending on which applies). For reporting/review purposes (see below), the system will treat the old designation as equivalent to "CrdtRcvd" (meaning, for those older items, it will still be up to you to verify via other means that credit was actually forthcoming).
"To-Grave" Improvement #2. As part of the above-described Ver. 4.3.99 release, we introduced a new filter and new report in the archived-PartsProcess form (Ctrl-F8) -- a pair designed to let you review, for appropriate management, those particular s/o items that had been ordered and received, but had no entries indicating a final and proper disposition. As per original design, those showings were somewhat general in that they included all items not yet in the grave, without segregation as to category. With this release, segregation is now offered. Specifically, when you pick either of those options, you'll next see a dropdown that asks what sub-categorization you'd like.
This menu option | This one |
![]() |
![]() |
Leads to this | Leads to this |
![]() |
![]() |
Thus (and as an example), if you want to specifically review items that have been returned to the vendor and on which you're awaiting credit, that specific category can be selected.
This brings up the point: to effectively harness the benefits as provided by Improvement #1 (described above), you should make it a practice, as you box up and send items back to your vendor for return credit, be sure to place them into the "RtToVndr" category. And, when you receive credit, be sure to go into the "RtToVndr" review category, eyeball the items on which you've received credit, and change their categorization to "CrdtRcvd"(this is the way to internally police, and truly assure the part is finally and fully "put to bed" every time, with credit having truly been received).
"To-Grave" Improvement #3. Recently a client pointed out that it would be very valuable to have a "Reverse PartsPickList." I was immediately and highly enamored of the concept. The notion is, it's a simple list (as provided to you on Tuesday morning, say) that shows everything that should be coming back from the tech, because not used from his work on Monday. Great -- I'd even say fantastic -- concept. I was immediately thinking, "Man, I want to make this ASAP!" But then, I thought, our "Parts Received But Not Disposed Of" report (above discussed) might actually (indeed, already) fulfill almost the same purpose. I pointed this out to the client, and he agreed that, yes, likely it would. However, he called back a short while later (having in the interim tried it), and indicated it really was not effective for the purpose -- by reason of the fact between techs that should have come back from the tech, versus others in the not-yet-in-grave category.
To redress that, besides the new sub-categorization described above, this release adds another: "In Tech's Possession" (see illustration above). It's not quite a Reverse PartsPickList, but (and for the time-being) it's a reasonably close facsimile.
Of course, there is the matter of how is the system to know that you actually (and physically) moved an item into the tech's possession? Until this release, there has been no formal designator of such fact built into ServiceDesk. However, many users have used the same BinLoc box (e.g., as used for designating "RtrnCrdt") for the purpose. More specifically, as they transfer a s/o part to a tech, they change that reference to his simple two-letter abbreviation. With this release, ServiceDesk will now recognize such a designator -- in particular, when applying the reporting/display filter that is the main subject of our "To-Grave Improvement #3."
FYI, as soon as I can do it, I'll create a new PartsPickList on-screen interface -- where you can simply click to indicate that items are being moved into the tech's possession, or back again. I'll also make a purpose-built Reverse-PartsPickList (as requested by that fine client) into an inherent part of it. Until then, you'll just have to do those changes manually.
"To-Grave" Improvement #4. This one, actually, goes beyond "to-the-grave" matters, but it was requested by another very clever client in the context of such concerns. He expressed the need for a method via which a tech can document why he ends up not using a part as prior ordered. My initial thinking is that such comments will likely go into the underlying Request-Item's Notes section.
Thinking about that particular Note section's use (for this added purpose), brought to mind two complaints users have made in its regard. To clarify, I'm referring to the large Notes section as found in the underlying Request (Alt-F8 form), not the smaller Notes section as found within a Process-Item (F8) band. One complaint has been that, when you're in the PartsProcess area, that larger section (which may have info you really need to know about) is not readily or automatically visible (you have to right-click in the Reference section to bring up its containing/underlying request). Another is that, once the Request item is archived (Ctrl-F8 form), those larger notes are no longer available at all.
This release address both matters. Regardless of whether you're in the Current- or Archived-PartsProcess forms, ServiceDesk will now display any underlying Request-Notes, in a ToolTip-type fashion, as your mouse floats over a process-band to which such notes are applicable.
Provision for the tech to document why he did not use an ordered part will be made in SD-Mobile (watch for updates there, along with mechanisms for such info to also auto-insert into these now much more available Notes.
Improved Item Selection When Printing Inventory Parts Labels:
When you're checking a shipment of new inventory via the F10 form, the dialog asks if you want to print labels for the items checked in. As a rule, it's best to do the printing at this point, because we've lacked a means to specify specific/particular items for label-printing thereafter. To clarify, you've been perfectly able -- after the fact -- to print labels for all of the parts in a given location, or all of a particular part number. You could even print one label as pertaining to a particular number, but with no ability to specify which instance (of multiples you might have in stock) that particular printout would pertain to.
This release solves that. Specifically, when you choose to print labels as pertaining to a particular part number (from the F10 form use the option sequence "Review existing inventory" and "Find qty and locs of specific item," pick an item, then click on the "Print list/labels" button), you'll get a list showing each instance.
Just pick the particular listings you want labels for. To select multiple items, user the standard Windows multi-select tricks (i.e, use Shift-Click on other item to select a range, Ctrl-Click to include or exclude an added item individually).
Font Color and Other Options Added to the Up-Front Ticket-Printing Setup:
These days technology moves fast, and we'll admit that even here at Rossware we are somewhat surprised to have so soon reached the point where -- viewing you guys out there -- we see printing tickets for service (at least prospectively from the office) as a bit quaint and old-fashioned. Most modern, we feel, is to have no paper tickets at all, and instead E-Tickets are provided to the customer via Mobile (a shameless plug here for that product). A large number of users have migrated to this model, and, if you have not, we encourage you to do so.
Regardless, we're not yet ready to stop injecting improvements into such tried and true methods as printing a beautiful ticket in the office, and sending the tech out with it. For a comparison, eye glasses are now a very old technology. But if you're going to use eye glasses, certainly you want the best that current technology can deliver.
Recently a user pointed out that it would be useful if he
could specify particular colors for particular items of text within the up-front
ticket. It seemed to make a lot of sense. Current updates in both
ServiceDesk and the SD-Tools utility allow you to do this (both will need
updated, the latter to Ver. 4.3.7; it's part of the SD-Update download unzip,
but unlike ServiceDesk itself will not automatically copy from station to
station). Additionally, you can now specify
FontUnderline and FontStrikeThrough as
characteristics. Just use SD-Tools for such setup, as per standard.
Of course (we should not need to say this, but you'd be surprised),
you'll need to use a color printer to make it work.
Password-Protected SD-LogIns:
Occasionally, we've had requests to make ServiceDesk operation subject to a password protected LogIn (i.e., you can't open it unless you provide a LogIn password). This release adds the option to setup any station to operate in such manner.
The setup and operation is similar to a function we added a few years back, to allow password protection for a particular tech's LogIn to TechWindow mode (see notes accompanying Release 4.2.22). Basically, you need to go to the Security/Password form (Shift-F11). Within that form's Users page, provide a unique password for each/any user whose SD-LogIn you wish to protect. In the second column (next to each such password), type the user's name precisely as it's listed in the Settings form (Ctrl-F11).
That's all that is required for setup. To test, go to the station as setup for any person for whom you've just done the above. When you go to open ServiceDesk, you should find there's a demand to present the password as setup for that user, or ServiceDesk will not open. (Actually, your Master password will also work, and potentially some others for other-user-LogIn purposes; see below.)
Improved "Hot Bunking":
We've also had occasional requests from users to better accommodate the situation where you have a single computer that's used by multiple persons (e.g., on the morning shift it's Sue, while on the afternoon it's Bill).
For nomenclature context, a parallel situation arises sometimes on vessels at sea (ships, submarines, etc.) where there are fewer bunks than sailors. What happens is, two (or potentially even three) sailors end up sharing the same bunk. But not at the same time. :) Each of the bunk mates has staggered "watch" times -- so that, as one sailor goes off watch, he awakens his bunk-mate, who tumbles out as he tumbles in. This has historically been called "hot bunking," and of course you hope your bunk mate has excellent hygiene.
ServiceDesk has long had various forms of hot bunking. There, is, for example, the Temporary Desk Reassignment feature (Alt-K). It's also easy to change the directly-registered user via the Settings form, on an as-frequently-as-needed basis. And, you can handle such needs via the Windows Users feature, where -- under any particular Windows LogIn -- ServiceDesk recognizes a unique setup/user, as tied to the Windows User, and reacts accordingly.
But aside from and beyond the above, some users have wanted ServiceDesk to offer the ability to do a direct LogIn -- to itself and under one and same Windows "User" LogIn -- wherein the ServiceDesk LogIn, in itself, recognizes a unique ServiceDesk user. This likely should be called "Native" hot bunking.
This release allows you to optionally setup for that.
To implement, just setup your hot-bunking station with a general Password-Protected LogIn (i.e., for a primary user, as described above). Make sure the intended bunk mates are in your Settings' form "List of Station Names," and that you've setup the same kind of unique password for each.
That's it. No more setup required. However, a tiny explanation might be.
Here is the trick. Let's suppose Sue is setup as the primary/designated user at your hot-bunking station. Sue does her morning shift and closes ServiceDesk. Bill arrives for his shift, and goes to start ServiceDesk. He's presented with the demand for Sue's password. He doesn't know Sue's password, so obviously cannot present it. He does know his own, however, and so types it instead. ServiceDesk, upon seeing Bill's password, knows that it cannot open itself with Sue as a user, but figures -- "Hey, I might as well open with Bill as the user," and does so.
It's that simple.
Except . . . one more thing. You might want to advise Sue that, if she doesn't want to get blamed for things that stupid Bill does during his shift, she'd better be sure she closes SD as she leaves (otherwise, of course, Bill might happily work under her LogIn).
Integrated Time-Card Punch-Ins:
One more matter, closely aligned with the above two improvements, concerns the fact that some people have wanted to have the Time-Card punch-in tied to logging into ServiceDesk. That's another thing that will happen with this release forward -- assuming just two simple elements in your setup: (1) you must setup the user for password-protected login, as per description above; and (2) you must have them designated, within the Earnings Rate form (Alt-F2), as an employee who is paid on an "hourly" basis.
Fix for "Auto-check old items as fully processed":
Back with release of Ver. 4.4.57, we added feature in our
"to-the-grave" parts management system where, if you were an established user
and been processing parts in an earlier era, you could auto-clean your old
legacy history, so items not marked as fully sent to the grave -- back then
(there was not mechanism for doing so back then) -- would not come up in a
current report. It turned out that cleanup process did not fully do the
intended job in some circumstances. That is now addressed. You can
access the check-off procedure from the PartsProcess form's (F8)
CheatSheet (right-click in any otherwise unused space of the form, then
look for the very bottom item in the menu).
New "Core Return" Functionality:
In the last couple of years, we've been working with increased vigor to "invade" the CE market. We feel determined, eventually at least, to attain the same dominance there that we've worked so hard to earn on the appliance side. Yet, even on the appliance side we've been subject to a small deficiency in that ServiceDesk has had no element specifically designed to manage core returns. Since core returns are relatively uncommon with appliances, it's not been a major fault there (back door approaches, though less than ideal, have largely sufficed). But on the CE side, by contrast, core returns (and whether they're managed with competence versus poorly) can easily make or break a company. HUGE dollars can be tied up in cores, so the lack of a feature explicitly designed to manage cores has been a serious matter.
This release addresses that.
To specifically acquaint you with how the matter is addressed,
we have added a new section to the manual's chapter-division on the PartsProcess system.
As it happens, this particular division is already excerpted for you in a .pdf document that's
contextually convenient by
clicking on a little provided button in the top-left corner of the F8 form (look for
the last sub-section within the document), or here's a
hyperlink. Please read the added section in that division, as it will provide
all needed details.
New "Jobs Profitability" Report:
We thank Don at Dependable Services for this addition. He insisted that a method was needed to have an instant snapshot of profitability on each job. Makes sense when you think about it. Man, you mean we didn't have that?
The new report is available from the Reports form (F11).
At this time the report should be considered Ver. 1.0. On the one hand, it may presently have flaws. On the other hand, it will likely be subject to significant improvements as time goes by. We expect to have input on both matters, and updates in the future.
One thing to note is that, like many of the reports, this one
also features an export. The export offers some details that are not in
the direct printout.
New "CE" Customization for UnitInfo Form:
If you do not know, "CE" stands for Consumer Electronics (these days, mostly big-screen TVs).
You likely do know that, in general, ServiceDesk was born and bred within an appliance service operation -- a fact which (and with apology to the rest of you) gives it something of a bias in that direction. This is also a factor we are endeavoring to overcome. We are very determined, in other words, to make ServiceDesk just as perfectly suited for other industries (in particular, HVAC and CE service) as it is for appliance repair.
Quite a while back, we learned that HVAC servicers wanted some other fields in the UnitInfo form (shortcut access for that form is via Shift-F12) -- fields to keep track of details such as unit fuel type (gas, electric, etc.), flow direction (up, down, sideways), and so on. To accommodate, we made the UnitInfo form vertically expandable (via a little arrow button at the bottom), and added the desired fields within the expanded space.
Recently we realized CE servicers need a field to keep track of particular units' Chassis Numbers (considered a model sub number), and the ability to search on that field as well. To accommodate this, we figured we needed to make the expansion area work in an alternate fashion: to show supplemental fields as needed for an HVAC operation if that was the kind of user, or to show CE-supplemental fields if that was the kind of user (or perhaps no expansion at all if neither user-type was applicable).
To implement this strategy, ServiceDesk needed a means by which to be informed as to the type of user applicable. For that reason, in this release we revise the Settings form (Ctrl-F1) to accommodate a new setting:
Depending on which option you pick for the above new setting, the UnitInfo form will be expandable (or not) in an appropriate manner. If, specifically, you pick "CE," it will be expandable (from this release forward) as follows:
If you are either an HVAC or CE servicer, please be sure to activate that new setting option as needed.
Improvement for "Anticipatory Parts Transfers" (Now Titled "Pre-Screened Parts Tagging"):
Way back in '05 (in Ver. 4.1.103), we introduced a mechanism that allows you to speculatively transfer parts, from your in-office inventory and to a tech, for potential use on a particular job. The notion is you may have items on the shelf, not normally kept on the tech's truck, and during the pre-screening process you may realize that a particular job will very likely need such a part -- making it sensible to pull it from the shelf and send the tech out with it.
Over time it's become evident that, though very beneficial, there were elements in this system we might have designed better. In particular, the implementation sequence invited you to transfer the part to a tech, at the same time you were tagging it (for potential/speculative use) on a particular job. This was based on the notion you'd likely know, at the time, which tech would be doing the job. As it turns out, however, this assumption was very flawed.
In reaction to the above, some of our more savvy users have taken to performing a little trick. When in the process and invited to pick a "Transfer To" target (i.e., which tech's inventory location the item is being moved to, from the office, for speculative use on the job), they've picked the office itself (i.e., "OF"). This results in no net transfer of location, but nevertheless allows the other part of the process (tagging the part to the job) to nevertheless take hold. It's a great expedient, but is also one that the involved language and processes would not normally lead a person to consider. This is so true that, even here at Rossware (and when consulted on the conundrum which the expedient solves) we have sometimes failed to remember it, and have occasionally instead been misled -- ourselves -- into thinking the structure allowed no such solution.
Because of the above, this release makes some changes.
First, we have changed the caption as found on the button, within the JobsCurrent (F7) form, that initiates the involved process. The old caption ("Antcptry Prts Trnsfr") was misleading for a process where, in immediate consequence at least, no true "transfer" was necessarily involved. Now the button instead reads "Tag Part for Visit" -- a phrase that much more accurately suggests that your purpose, when clicking on the button, is (necessarily) to tag a part in such manner as to facilitate its presence with the tech -- with any tech -- when he next goes to the site on that job.
Old | New |
![]() |
![]() |
Second, as title for the overall set of processes, we are changing from the term "Anticipatory Parts Transfer" (or sometimes "Speculative Parts Transfer") to the more accurately descriptive: "Pre-Screened Parts Tagging" (as per title/header for this WorkDiary entry).
Third, when you actually click on the involved button, there is a new query, as follows:
As you can see, you are now invited to choose, explicitly, whether you want presently to Tag-Only, or Tag-plus-Transfer. This makes the alternate potentials much more apparent.
Fourth, if you choose the Tag-Only option, the system will (logically) skip what was otherwise a following window in which your were formerly asked to pick the "Transfer-To" location.
Fifth (and perhaps most importantly), there is a newly-augmented process as now connected to the system. Assuming that in fact you've "Tagged-Only" while pre-screening, this process recognizes a subsequent need. Specifically, sometime prior to the tech heading out on any particular day's set of jobs, you'll likely be printing a PartsPickList, and using it as the basis to actually pull tagged items from the office, placing them into an applicable tech's pickup bin. Once this is done, it's imperative to inform the system of this physical transfer event (i.e., so it can properly tally where the item is now at -- referring, specifically, to those instances where you did not claim a transfer initially).
Ultimately, what we really need to do to -- to optimally accommodate this purpose -- is to have an interface that will likely be called (at least something like) the "PartsPickList-Reconcile" form. The vision is for this form to provide a one-stop place for a parts-puller to assure he's assembled all the parts a tech should be taking with him for his day of jobs, whether as special-ordered, speculative-tagged, or simply needing restock to inventory (and, of course, to seamlessly document the movements from one location to another). It may be that the current Parts-Crossover form can be optimally adapted for this purpose, rather than creating a new interface in its entirety.
Regardless, in an anxiousness to "deliver" on the current project, we have for now refrained from creating an entirely new interface. Instead, we've added enhanced functionality to a pre-existing function.
Specifically, in the InventoryControl form (F10) there has long been a function to facilitate transferring parts to a tech for the purpose of restock (in particular, using as basis examination of items on which he's fallen below minimums). It's a very smooth and well-developed process. Our new function allows you, simply, to use this same set of mechanisms, but in a context that's augmented so that the system lists not only regular inventory items as needed, but also any items as tagged for jobs the technician will be doing for the day in question (and which have not already been marked as transferred to him). Thus, it's a solution that allows you to (please pardon the cliche) "kill two birds with one stone" (accommodate ordinary re-stock, plus appropriately move items speculatively tagged).
To invoke this augmented process, you'll notice that when you choose to print a PartsPickList from the DispatchMap, there is a new option box in the resulting Printer-Selection form:
If you print with that new option box checked, you'll find that, besides printing the traditional list, the system takes you directly into the InventoryControl form's newly/specially augmented Transfer-for-Restock mode. In this mode, it will list not only normally-needed restock items (as it always has), but also ones that need moved to him because they've been tagged to a job that is on his schedule for the applicable day. Such items will be distinguished, from normal restock items, via the text being in red.
From that display you can use traditional/normal means to transfer all items, both normal restock and job-tagged items, to the tech as needed.
Besides those particulars above-described, a few other elements of language and interface have likewise been appropriately changed. Even so, please note we have not entirely dropped the "speculative transfer" language. This is because, even if you do not transfer to a tech while tagging a part, you very likely DO transfer the evening prior (or morning of) his dispatch on the job. For such particular operations, the older language is retained.
BTW, we realize there's a downside in changing terminology. Please be assured, we resist doing so except when there's a large purpose to be served. We believe this instance strongly qualifies.
Enhancement for POS-Context Special-Ordered Parts:
Until now, there's been no distinction by the system when you check-in the final part, as ordered on any ticket -- as to whether it was a POS-context (versus more standard repair context) order. It turns out the distinction is important. Among other things, if in repair context it's natural to assume that, once all parts are in, the underlying JobRecord should be placed into "WorkingToSchedule" status. Not so if it's a POS-context order, where there's no return/repair appointment needing to be scheduled. Similarly, any dialog (such as in an auto-generated email as designed to inform the customer of part arrival) needs to be appropriately different, if it's a POS-context order.
Prior to improvements as made in this release, the system
acted as though every order was a repair-context order. But now, with
improvements as presently made, the system will distinguish the two contexts, and
handle the POS variety much more adroitly. (For the distinction,
incidentally, the system looks simply to the underlying JobRecord's narrative
history for the phrase "(POS context)"; if that's found, it deduces
accordingly.)
Enhancement to DispatchMap's Show-JobsNeedingScheduled Feature:
Now Includes JobsWhereCustomers"Want-Sooner":
A few people have asked for this over the years, and finally we did it.
First, the general Callsheet/JobRecord structure has a new little check-off square. It's similar (and in fact right below) another tiny check-off that we added a few months back (see entry accompanying release of Ver. 4.4.62). That one was added for the purpose of denoting if a job should be classified as an in-shop repair (i.e., "ShopJob"). This new one is designed to denote if, though having accepted a particular appointment, the customer would nevertheless like to be moved sooner, if possible.
Prior to most recent addition | With most recent addition |
![]() |
![]() |
You may note (by reading notations in the above illustration), the RED color as formerly used for the in-shop designator has been usurped by the new check-off (though at least its physical position remains constant). In general, we hate to change a functional color, but it seemed that red made eminently more sense for a designator that really should attract notice (this customer would like to be re-scheduled for sooner) -- as compared to something mundane like designating 'in-shop' status. Thus, the old designator now gets blue.
So far as on-screen labeling and reminders go, just as with the first designator, there are ToolTips available to assist (just float your mousepointer over either item, and the ToolTip should appear).
Now, for actual benefit . . .
Aside from toggling the new designator (again, to indicate the customer "Wants Sooner"), you're going to want to employ those toggles.
In your DispatchMap (F5), there has long been a "View-JobsNeedingScheduled" feature. The idea behind it: at any moment and on any day's schedule, you can toggle-on a view of jobs that need to be scheduled. So, if you're looking at a schedule and needing to fill it in (or at the fact some tech is driving a long distance and you'd schedule more jobs in that vector to make his trip more worthwhile), this feature can show you good candidates. The item references appear as little orange "pumpkins" on your map, and you can click on any to display the full/underlying JobRecord.
The feature is toggled on (or off) by hitting "J" on your keyboard (think "J" for "J"obs) . The DispatchMap's contextual "Cheat-Sheet" has long had a little hint reminding of this method (right-click on any otherwise unused position in the DispatchMap to display). That particular hint has now been changed, however, to describe a broader purpose.
Old description from Cheat-Sheet | New description |
![]() |
![]() |
Put simply, the old "ShowJobsNeedingScheduled" feature now does more than to show you just the orange pumpkins.
As you can see from this example, the system now shows green pumpkins too. These new pumpkins represent jobs that are presently scheduled, but where the customer would love to be moved to a sooner date ("Wants-Sooner"). Aside from noting that simple difference, you can use them much the same as you do the orange pumpkins.
Two Small Tweaks:
First, tweak one. A couple of years back, ServiceDesk's Printer-Select form was enhanced to allow (in appropriate contexts) destinations other than actual printing for the the product destination: specifically, Email or File.
At the time, it was setup so that any of the three potential destinations could be independently checked, or not, as to whether the product would go there. In other words, it was not setup to "toggle," such that if your picked Email, say, it automatically un-checked Printer. The thinking was, you might want to do both (or perhaps all three), so the check/activation for each was independent.
That was fine in theory, but in practice it was much more typical that you'd want one function only, which made it kind of a nuisance that, if the form prior had Printer selected, and you now wanted to switch to Email, you needed to do two things: un-check Printer, then check Email.
This release addresses that. Now, selection of any of the three alternates un-checks the others for you. If, in fact, you want to do multiples at the same time, simply hold down Ctrl on your keyboard, while making added selections.
Now, tweak two. If you examine your Callsheets (and
assuming you're in an office with multiple users), you're likely to notice a
small difference. Callsheets as assigned to others will show with all text
in a grey color. This makes it more evident when a Callsheet is not
assigned to you, and we think you'll like the difference.
Exciting New DTR-Viewer:
What is a DTR-Viewer?
First, DTR stands for "Daily Time Report."
Second, the improvement builds on a feature I added to SD-Mobile some six months ago. There, I made it so each of your techs can easily see (and optionally certify as accurate) a graphic overview of their time spent during the day -- a beautiful image that provides a "mental picture" of the time periods spent "Punched In" on the clock, and -- of that Punched-In time -- which portions were spent working at actual jobs.
When I made the above-described improvement in the mobile interface, it was my intent to quickly provide the same visual overview for managers in the office. Though it's taken me a while, that next step is now ready for your enjoyment.
To use the new DTR-Viewer, first go to your DispatchMap (F5). Page-up to view any past/prior day, then hit Alt-T on your keyboard (think 'T' for 'T'imeCard). In result, you should see something similar to the following:
As you can see, there is a TimeBar for each tech, showing all Punch-Ins and Punch-Outs for the day, with time "on-the-clock" showing in red (any breaks between first punch-In and punch-Out, such as for lunch, are shown in white). Time at actual jobsites is shown via green inserts, appropriately labeled for the jobs to which they pertain. Given this dynamic, you can easily gauge (and at a glance) if, when and where your techs spent significant amounts of time on-the-clock, but not working at actual jobs. In other words, look for large areas of red (such areas being NOT a good thing). Wherever you see such areas, you may logically be prompted to inquire as to whether the tech properly should have been "on-the-clock" during such time.
There are also helpful statistics at the top. Among other things, these help you compare between techs to see which are being the most efficient with their on-the-clock time.
There are more tools still. If a tech manually inputted a punch-In or punch-Out, for example (i.e., rather than allowing the TimeCard system to go by his computer's internal time when he punched In or Out), the corresponding time notation will show in red, to signify this fact. If the technician used the SD-Mobile mechanism to certify accuracy in his DTR (a practice we suggest you insist upon), you'll see a very large check-mark in the white space immediately above the TimeBar itself (just to the right of the statistics). In fact, the check-mark will be green if the presently calculated total of time agrees with the indicated time when he certified, or red if there is now a discrepancy. If you want to change the day that's displayed, use PageUp and PageDn from your keyboard, just like when inside the DispatchMap.
We think you're going to find this is a more than fantastic tool. And don't worry about memorizing the shortcut key to access it. A reminder is in the DispatchMap's CheatSheet.
As one more (and super-handy) feature, if you're looking at any particular job notation (green rectangular insert) and are curious to see details about the actual job, just click on the notation. Instantly, the underlying JobRecord will display for you.
QuickLink to Particular/Underlying A/R-Item via A/R-Dunning Form:
For the last three or four years, just about every time I'm working on the line-items list in the A/R-Dunning form (Ctrl-F3), I find myself having the natural urge to be able to right-click on any particular line-item, and have displayed the complete A/R record which underlies it. Sometimes, after all, as you see the simple line-item summary, you want to know more details about that particular A/R. It's just not right that you have to hit F3 (to bring up the A/R form) then conduct a search in it for the item of relevance.
Finally, I made the time to program in this "should-have-been-there" convenience.
As you can see from the illustration, a ToolTip is now available to remind you of the new convenience. Just float your mousepointer on the little grey label area at top of the form, and the ToolTip will appear.
As a moderate little enhancement of this feature, if the line-item that you click on happens to reference multiple A/Rs (i.e., rather than a single one, as is more typically the case), the first quick-linked item as displayed will be the first/oldest. However, the A/R form will be pre-configured for you in "Search" mode, with the 'Resume Search" button showing and pre-selected. This means, to rotate to other A/Rs as applicable to the line-item linked from, all you need to do is hit Enter on your keyboard.
Thus, you have quick and easy access, even to multiple
A/Rs as connected with any single Dunning List line-item.
Solution for Multiple Mfrs Who Use Identical Part Numbers::
We've been informed that, increasingly, servicers are running into situations where different manufacturers happen to end up using precisely the same part numbers as one another -- but of course each for their own (and different) parts. The underlying structure of SD's inventory system is one that uses the part number as a controlling entity, and without regard to applicable make. This means part number duplication, between manufacturers, has been a potential issue.
This release introduces a solution, though perhaps not quite so perfect as user might have otherwise desired. It's sort of a work-around.
What you need to do, for any part where you're stocking different items but of the same part number for different manufacturers, is append one or both instances with an asterisk then a single letter that indicates the applicable manufacturer.
For example, suppose both Toshiba and Sony have parts bearing part number 123456, and you want to stock each. For the one from Sony, make your within-the-MasterPartsPlan number "123456*S". For the one from Toshiba, make it "123456*T".
The above is, of course, an expedient you could have been using all along, but with one downside. When ServiceDesk fills-in the on-screen Narda for a warranty claim, it uses your part number as provided. Sony won't likely provide credit on claimed use of part number "123456*S". That's where the improvement (as present in this release) comes in.
Specifically, with the enhancement as introduced with this release, when ServiceDesk fills in the on-screen Narda, it will look for part numbers with a "*X" suffix on the end (where "X" is any possible letter). For any found, it will delete the suffix -- thereby smoothing the way to a successful claim on such parts.
Fix for "Split A/Rs" ending up in presentation of multiple "tickets" to consumer:
There have been prior references in this blog to "The Law of Unintended Consequences," and it is, sadly, a merciless (if sometimes slow-to-present-itself) taskmaster. Slightly less than five years ago (see entry for Rel. 4.1.74), I introduced the ability to make interim sales entries: entries to the sales journal for a portion of the sale as already earned, and prior to a completing entry, for the balance, which actually closes out the job. Turns out there as a down side to using this practice. If the interim entries were for billed work, and if you later sent the client a statement for outstanding A/Rs which involved such multiple entries, it was possible for the statement to have multiple line items for what was really a single job. This could potentially be confusing to the customer, and cause unwelcome objection. On top of that, if you happened to be creating a new job for such a customer, there's that little feature that offers to add a note about presently unpaid A/Rs. That note could end up claiming there were multiple A/Rs, even if all involved a single job (and again result in confusion with the customer).
This release remedies both issues. In either of the contexts described, ServiceDesk will combine the multiple A/Rs (as under a single ticket number) and present them as though one.
Fix for Un-Indexed Secondary-Party Info as Connected to Shop Jobs:
There are, of course, "two" party-info sections in SD's general Callsheet/JobRecord structure. The second is only used (at least for actual party info) in the event a job actually involves two parties (one for billing, and the second for go-to). Of course, when not used for official party-info purposes, the second section is sometimes used (and at least by some folks) as extra space for added notes. This particular fact creates a quandary for the system when it updates the CstmrDbase Index set each night. If extraneous notes are in the second party-info section, we do not want to have such notes indexed as though they consist of a party's name, address and telephone number, etc.
The solution has been that the Index-updating machinery is programmed to ignore text within the second party-info section -- unless if finds (in the address box) a set of brackets, as involved in the grid coordinate that's inevitably put in if you're sending a tech to a location as involved in that section (bear in mind, while it's easy for a human to look at text and distinguish between text that describes a name, address and telephone numbers, computers are much less capable of so simple a task).
The above works fine, except where you're doing a bill-to-another-party Shop Job (typically, involving a TPA payer). In that case, you need the second party-info section to describe the owner of the merchandise you're repairing, but you do not need brackets in the address line, because there's no need for grid coordinates on an address you're not sending a tech to. For that particular situation, our trusty old strategy fails.
In solution, this release introduces a change. From here
on out, the system looks to see if the first-section party info describes a
HighVolumeClient. If so, it will index text in the second section, even if
no brackets are found there.
Improved Mailing-List Export:
One of the oldest exports in ServiceDesk is the MailingList export (available as the first option in the Alt-F3 form). As time has gone by, I've improved my overall export-programming standards. The present standard allows you any of three formats (.csv [comma-delimited], .txt [tab delimited] or .xls (Excel format). Plus, it offers to open the file for you, upon its creation. I recently discovered this old export had not been brought up to the current standard. That is now addressed.
Vastly Overhauled and Improved Connections to the Mobile Ticket:
Back in November of last year (with release of Ver. 4.4.38) we added the ability to directly review and edit, in the ServiceDesk FinishedForms context, tickets as created by the tech when operating in SD-Mobile (simple image-based review had always been available). This was a major step forward in terms of integration between the two systems. However, we found there were occasional glitches in the technology we were using to make the connection between ServiceDesk and the remote database that serves as a common information point between ServiceDesk and the Mobile techs. This sometimes resulted in difficulty when seeking such direct-access of the mobile tickets.
With this release, we have switched to an entirely new technology for such connection purposes, and it promises to be much more reliable and fast.
While testing operability of this new technology, I noticed
some shockingly severe defects in how the program code was prior loading data
into the FinishedForm tickets, and sometimes in saving edits too. I am
embarrassed, frankly, to have discovered such large defects were there, and had
evidently been there since September. They also have now been fixed.
New "Quick-Link" in Inventory-System Forms:
There's long been ability in both the InventoryControl form (F10) and MasterPartsPlan form (Ctrl-F10) to do a Ctrl/Right-Click on any line item to invoke an immediate show as to locations and quantities for that item. It's extremely handy. Say, for example, you're looking in the F10 form at items that need to be restocked, and you want to how many you've got an where; a simply Ctrl/Right-Click on the line-item will tell you. Or maybe you're reviewing items in your MasterPartsPlan, and are curious to know for a particular line item what you've got and where. Again, a simple Ctrl/Right-Click will tell you.
Recently, I realized another/similar quick-link would be very useful. Instead of instantly showing you locations and quantities for a particular item, it will instead instantly show you the history of movements (purchases, sales and transfers). The command for this new link is Shift/Right-Click.
Don't feel any need to memorize that command on the basis of description here. It's been added to the contextual "Cheat-Sheet" (as applicable in either of the two forms), as follows:
Remember this cheat-sheet (and others in their own applicable
contexts) can be displayed by simply right-clicking with your mouse in any
otherwise non-functional location on an applicable form.
New Filters in the Jobs-Perusal Form:
We find some people don't even know about this form. It's accessed via Shift-F7. The general idea of the form is it allows you to review a limited set of jobs -- such as, for example, only those that are in Working-to-Schedule status. The main filters (i.e., criteria by which to limit the set of reviewed jobs) are JobStatus, but there have long been others, such as applicable technician, for example. If you haven't used this form, we highly suggest checking it out, as it's very handy.
This improvement concerns two brand new filters:
The above illustration is really sufficient, in itself, to
tell you what the new filters are.
Improved Designator for "ShopJobs":
Until about 30 months ago, there was nothing in ServiceDesk functionality to operationally distinguish between jobs as setup for in-shop work versus those setup for in-field/on-site service. However, a few servicers described the need for certain kinds of distinguishing treatment, so the program code was enhanced to provide the same (see description accompanying Release 4.3.45). At the time, we used kind of a "cheat" method to facilitate designation, of any particular job, as being in-shop (as opposed to the default assumption of on-site). Quite simply, in the LocationName box you'd type the magic phrase "SHOP JOB." In result of seeing such text there, ServiceDesk would realize it was a shop-job, and react accordingly.
This has been the solution until now. It's worked fine, except for the fact the designation method was perceived by some as -- shall we say -- inelegant. Certainly, it has been less elegant than would be having an actual checkbox for the purpose, and that is the matter now addressed.
In fact, I began working on the graphic interface for this improvement a few weeks back (since real-estate in the applicable forms is already tight, I could not simply add-in in a normally-labeled checkbox for the purpose; the applicable forms do not have space for that). You may have noticed my tentative solution when a couple of tiny new boxes appeared in the Callsheets. These were otherwise not-yet-operational, and there was no notice explaining their purpose. It was nevertheless my intent to program the first to default with a checkmark indicating the job was intended for on-site service, while providing the option to user-check the second, instead, to designate the item as a shop job. Initially, I got as far as making that graphic, but did not get any of the underlying programming done.
This past weekend I finally found time to do the underlying programming. Initially, I'd intended to go ahead and use the graphic interface as above described, but soon decided two checkboxes make less sense than a single one (why do you need a box indicating normal status, anyway?). The final scheme is, this single box defaults to a neutral color to indicate a normal, in-field-service job -- but can be user/click-toggled to red for the purpose of indicating in-shop service instead. So, that's what we've ended up with (with, as you'll note, the final/operational box also moved to a slightly different location, as compared to original intent).
Applicable Callsheet section without any check-off designator |
![]() |
With interim/abandoned modification, showing boxes as intended for toggled/alternate checkmarks |
![]() |
Design as finally settled upon (here shown with new checkbox NOT toggled) |
![]() |
Also showing new/actual design, but with new box toggled to indicate job is intended for in-shop work |
![]() |
Naturally, this new little designator has been added not just in Callsheets, but in JobRecords (current and archived) too. Simply click on the little box in any such context, to toggle it red, any time you wish to designate the job is intended for management as in-shop work. Or, click again to toggle back out. Again, it will show in a neutral color (same color as the surrounding background) if it's a standard job, or as red if toggled for in-shop. Also, if you float your mousepointer over the new little box, you'll see a ToolTip come up to remind you of its purpose.
Ideally, it would have been good for me to include with this
release conversion code that would go through all present and past jobs, search
for the old mode of designation (i.e., the phrase "SHOP JOB" in the applicable
location), and change the new designator to match. Alas, I did not find
time for that. However, for a reasonable transition period ServiceDesk
will recognize either old or new designator methods as legitimate. In
other words, whether it finds the phrase "SHOP JOB" in the expected box, or if
you've toggled the new little checkbox to red -- either way it will see the job
as being intended for in-shop management. From this point forth, of
course, you should use the new designator, and abandon the old.
Fix 1 for Built-in Self-Protection on Filing Warranty Claims:
The "Law of Unintended Consequences" is the programmer's eternal enemy. Turns out, the scheme (as described immediate below) was great for most servicers in most circumstances, but resulted in unnecessary annoyance for others. The biggest immediate issue concerned claims as submitted on extended service contracts, where a purchase date more than one year ago is not an issue.
With this release, the system should detect when it's an extended service contract situation, and refrain from making the "purchase-date-more-than-one-year-ago" warning, if so.
Another issue involves servicers that do large amounts of
work for premium companies, such as Sub Zero, where the typical warranty period
is more than one year. My intended solution (it will be "Fix 2") for that
is to provide a new box, in the Quick-Entry templates, where you can indicate
for each manufacturer what their typical warranty period is. Alas, I have
not yet been able to get to that added project.
Built-in Self-Protection on Filing Warranty Claims:
ServiceDesk has long made rudimentary checks as you go to file a warranty claim via the on-screen Narda. It cannot, of course, fully predict if the underlying processor will accept your claim, but at the least it can look for (and warn you about) a few common errors. As mentioned, it has long had this facility.
However, it was recently pointed out there were a few logical (and relatively rudimentary) checks it was not making. Specifically, it was not looking at the DateOfJobInception, DateOfCompletion and PurchaseDate fields -- to cross-compare between those and with the current date -- to assure such date comparisons would not be likely to result in claim rejection and/or embarrassment. Those checks are now made, and (assuming the comparisons indicate a likely issue) can result in messages such as the following:
I'll confess that manufacturers, on seeing we've done the
above, might suspect the effort is aimed at facilitating cheating by you, the
servicers. Let me assure, however, that is not the case. At
Rossware, we generally find our users have a high level of integrity. The
real concern is that accidentally-inserted erroneous dates can result
in claim rejection and/or embarrassment. These messages give you the
opportunity to consider if less-than-sanguine dates might in fact be erroneous,
and to advance correct (i.e., prior to actual submission), if so.
Facilitated Parts Returns:
In conjunction with Whirlpool Corporation, we have implemented a system to facilitate returning, to them, parts they need back for fault analysis. Basically, any time you check-in or go make a claim on any part within a particular "we-want-it-back" return list, ServiceDesk will automatically produce a message telling you Whirlpool wants it back, and offering to print documents to facilitate the return (specifically, a packing list and postage-paid shipping label).
We believe, in result of this work with Whirlpool, we've
created a model of facilitated returns that may eventually be used by other
manufacturers, both in appliance service and other repair industries.
Improved "Cheat Sheets":
ServiceDesk has long possessed a Command Summary in its main menu. A listing of commands is particularly needed for some contexts, because in some (such as the DispatchMap, for example) display space is so much at a premium for operative purposes, and the operations that we wish to do are so many, it simply is not practical to provide on-screen command buttons for every purpose. Instead (and in such forms), we offer a plethora of powerful tricks and tools via various combinations of keyboard and mouse. Among other things (and for each such context), the Command Summary lists what these actions are.
Augmenting that main-menu listing, it has long been easy in several such operative areas to quickly bring up the particular section, from the Command Summary, that's applicable to the context in question. When the apt section is brought up in such manner, we have taken to calling it a "CheatSheet." These CheatSheets can be very, very handy.
Gradually, some of these CheatSheets have been improved for greater organization and clarity, but until now some were still somewhat lousy, and we needed some new CheatSheets in places we did not yet have them. Plus, for each context where a CheatSheet was potentially available, you needed to at least remember the particular magic place, where you could right-click with your mouse, to bring up the Cheat Sheet as applicable there.
With this release, there is a big general improvement. In any context that offers a CheatSheet, you can now right-click in virtually any otherwise un-operative space, and get the CheatSheet as applicable there. The contexts that offer such CheatSheets are as follows:
Callsheets;
DispatchMap;
PartsProcess form;
ScheduleList form;
Inventory Control form; and
MasterPartsPlan
Please note that the last two forms are new, in terms of their CheatSheet participation. For those two contexts (and for some time), we've needed reminders of two or three potential commands in each, and those are now provided in these particular new CheatSheets (if you check in those contexts, you'll see some handy actions you likely did not even know were available).
Please also remember, a right-click in any otherwise un-operative space, in any of these forms, will produce the CheatSheet as applicable there.
In addition to the above general improvement (and added CheatSheet contexts), the CheatSheet as applicable to the PartsProcess form has been strongly improved, in terms of the clarity of its organization:
Old PartsProcess CheatSheet | New PartsProcess CheatSheet |
![]() |
![]() |
While the new layout may look a bit more intimidating in size, if you look briefly, you should see it will be a great deal easier to find what you're seeking when you want it.
New "Wholesale Check-Off" for PartsProcess-Items-Disposed-Of:
A year or so ago we completed the "to-grave" portion of our cradle-to-grave PartsProcess system. Specifically, we provided a report that explicitly lists items not checked off as having reached a proper disposition (i.e., used on the job, returned to the vendor, etc.). This was to provide you the basis assure no such items slip through the cracks -- that, ultimately, all reach an appropriate final destination.
For those transitioning from prior times, however, we discovered an issue. If you had not prior been doing check-offs, and yet wanted to use the report, you could find it filled with old items of which you're no longer truly concerned.
To address this, the CheatSheet for the PartsProcess form now has a new option (see bottom item in illustration of "New" above). If you click it, you can run a process to address the above-described concern.
Added Link-Convenience in DispatchMap Auto-Popups:
On the first of this month, we added popups in the
DispatchMap. If you float your mousepointer over any job reference, a
popup shows a bit of added detail regarding the underlying job (InvoiceNumber,
and Type and Make of machine being serviced). Based on popular request, we
just added a new element. If you do a simple click on the little popup, it
will open the underlying JobRecord for you. To be sure, a Ctrl/Right-Click
on the underlying reference will do the same thing, but in some instances you
may find it just a little handier (and perhaps more intuitive) to do the simple
left-click on the popup instead.
Miscellaneous:
Nothing terribly notable in this release so far as new
features, but it contains a ton of small fixes and tweaks.
Enhanced Internal Backups:
Virtually from its inception, each ServiceDesk package has included a superb backup utility called SD-Backup. The design intent is for this utility to run continuously at any computer aside from the server. In such a state, it automatically maintains five layers of backup (hourly, daily, weekly, monthly and yearly). As just one tool in your backups arsenal, it's an excellent system, and positively should be in deployed in every ServiceDesk office. If you have not been using SD-Backup, please fix that fact now!
Sadly, SD-Backup does not solve every need-for-backup situation. One problem is, some people (in spite of the fact ServiceDesk almost constantly pesters otherwise) choose not to run it. Seriously, we've had numerous people who suffered data loss -- then, to add insult to injury, they had to face our scolding for the fact that, though pestered every day by ServiceDesk to run SD-Backup, they'd still refused to do so. In some cases these folks had other backup systems in place, which they thought obviated the need for SD-Backup. However, the other systems proved to have not been doing what they claimed. Please, do not NOT use SD-Backup.
Of course, even when you're faithfully running SD-Backup just as you should, it may fail to provide a wanted salvation. This is particularly true because each hourly backup overwrites the previous hourly, and each daily overwrites the previous one in its class, and so on. Because of this, if you don't notice there's a fault in data prior to such an automatic backup, its class of backup will have replaced -- what was formerly a good backup -- with a defective copy. It's one of the Achilles' heels of automated backup systems (because of this, if you notice a major fault in any data, it's a good idea to momentarily terminate the SD-Backup program, pending immediate investigation and resolution).
Regardless of whether the issue is SD-Backup having not been running, or because it's already replaced a prior good backup with now defective data, we've often found another salvation when users have had data faults occur (no software, by the way, is immune from data failures when the underlying system hiccups in any of several possible ways). It's based on the fact that many processes in ServiceDesk make their own, in-process backup as the process runs (as a rule, these backups go into the LclData folder for station that's running the process). Virtually all the archiving processes do this, for example (Callsheets, JobRecords, ScheduleList, PartsProcess, etc.). Because of this, it's often been true that when we could not find an optimum backup anywhere elsewhere to use, we were nevertheless able to find a good in-process backup, and restore a user to good operating condition.
Even here, however, the results have sometimes not been as good as wanted. The major problem has been that, after having discovered a data fault, the user again runs a procedure where the same in-process backup is made. This overwrites the prior (and formerly good) in-process backup with a copy of the now defective data -- and very much frustrates our effort to make a good restoration.
This release will directly remedy that occasional deficiency.
Specifically, each station's LclData folder will now receive seven sub-folders, one for each day of the week. All in-process backups will to go the sub-folder that pertains to the day on which the process is running (meaning if there's a fault today and you already overwrote today's previous good in-process backup, there should still be backups in yesterday's sub-folder to look to, and so on).
And that's not all. Within each days' in-process backups folder, instead of each backup (as for that day) overwriting its predecessor (assuming its from the same calendar day), it makes a new one (appended with 001, 003, etc.).
Based on this, any occasion where we can't turn to an in-process backup for these critical files should now be very rare indeed. You still should/must be running SD-Backup as well (when it comes to backups, it's hard to have too many layers), and you positively should also have an off-site backup system as well (we recommend burning critical data to a CD on a daily or weekly basis, and taking those home, assuming home is not the same place as the office).
Improved "Unvlbl" Entries in the ScheduleList:
Another very old ServiceDesk feature involves the fact that, in the ScheduleList form (F6), you can create entries denoting times when a tech is unavailable. The method is to place, in what's normally the customer name space, any of three potential text strings:
(a) "Unvlbl" (for denoting a time-frame in which the tech can't work;
(b) "Unvlbl Until" (for denoting he'll not arrive on the indicated day until a particular time); or
(c) "Unvlbl After" (to indicate he'll be ending work at a particular time).
Also very old was a shortcut for inserting these key phrases. It involved typing either "U", "UU" or "UA", then hitting Shift-F3 on your keybaord, which made ServiceDesk change the short string into the somewhat longer full one. To be candid, in the last many years I've been embarrassed to show people how this feature works, because the method is so clumsy and un-Windows-like. I'd made the feature in my earliest programming days, when I still had a rather DOS-oriented mindset.
Anyhow, we recently co-opted the Shift-F3 command for displaying the new Rolodex, without realizing it messed up use of the same function for the above-described purpose. This made a perfect opportunity for modernizing the latter. Now, when you're in the F6 form's CustomerName box, you'll see a drop-down with the three magical options, and all you need is to select one.
New Boxes added to Hyperlink-Capable set:
We introduced drag-and-drop hyperlink creation a couple of
years ago, and imbued several of the textboxes (in various ServiceDesk locales)
with the capability. We also said, if people wanted the capability in
other boxes, let us know. Recently Scott at Carter Services asked for the
capability in two new places: (a) the Notes box of the PartsRequest form
(Alt-F8); and (b) the Notes box of a SpecialSituationsAdvisory (Alt-F11).
The ability is now added to those boxes.
Find Funds Received and Find Parts Special-Ordered buttons added to Archived-JobRecords form:
For quite a while, we've had a couple of handy, half-hidden functions in the Current-JobRecords form (F7). Some of the buttons there do alternate duty if right-clicked on, instead of the standard left-click. Of particular note here, the "enter funds Rcvd" button can be right-clicked for an instant viewing of all monies collected on the job; or you can right-click on the "orDer parts" button for an instant viewing of all connected parts-process items (you can float your mousepointer over other buttons to review their alternate functions, where applicable).
Last week, I got an email from Allison at Dependable Services asking for similar capabilities in the Archived-JobRecords form (Ctrl-F7). It made too much sense to resist, so now has been added (please understand, these are in-context, convenience searches; the same searches have always been available from within their own operational contexts, elsewhere). In the new context (and as you can see below), these "Show Me" functions are not alternate/back-door operations for the buttons involved. They are the exclusive, on-the-face purpose for each.
Before | After |
![]() |
![]() |
Since the updated form has the same quantity of buttons as before, you may wonder what we did with the functions those same button positions used to provide. On consideration, we realized those old functions did not need to be in this form. One of them ("Dbs Index Utility") already had separate access via the MainMenu, and we moved access to the other function there as well.
Old "File Functions" Menu | Improved and Simplified "File Functions" Menu |
![]() |
![]() |
In fact, we did not want to just keep adding items to that menu section (it was already a sufficiently long list as to be potentially confusing). Honoring that concern, you'll notice that an added element of work was to reorganize File Functions, placing several items into fly-out subcategories. This considerably simplifies the main list.
New Auto-Popups in DispatchMap:
I was given this idea by Steve at Gulgren's Appliance. You're likely familiar with Windows ToolTips: little clues and hints that pop up when you float your mousepointer over various objects (we use them a lot in ServiceDesk). We are now using something similar in the DispatchMap. If your mousepointer floats for more than 1/10th of a second over any job reference there (either graphic or list type), a ToolTip-like window will display, showing some added details on the job.
Currently (as you can see in the example above), the popup provides job InvoiceNumber, along with Type and Make of machine being serviced. I suspect there may be requests to add some more details, which I'll certainly be willing to consider. Please bear in mind, though, all it takes is a Ctrl-right/click to see the entire job, so it certainly makes sense to keep what's shown in this popup comparatively limited.
Improved Emailing of FinishedForm Tickets:
A couple of years ago we added the ability to direct-email
tickets from the FinishedForms context (Alt-F4). Occasionally since, we've
had complaints about legibility and clarity in the emailed images. It was
generally an issue only if the image included very small graphic-based print, as
in the disclaimer section of an underlying ticket image. This release
addresses those clarity concerns. In addition to the fact that such tiny
print will now be legible, the image files (as attached to the emails which the
method produces) will be now be in .PNG format, instead of the .JPG format as
was formerly used. PNG is a newer and more efficient graphic standard.
Even with much better resolution, it allows use of smaller file sizes.
Integrated PartsProcess Work:
When you're creating an internal PartsRequest via the Alt-F8 PartsRequest form (this is most typically done while in the context of a PostVisitReport Type-2), it's possible you are not merely the person creating the request: you may also be the one who needs to do the subsequent processing (i.e., inquiring with and/or ordering with a vendor). And it may be the case that rather than taking care of all pending on orders later, as a batch, you'd rather do it directly in-line with creation of the request. If so, this new feature is for you.
Quite simply, if you want to link directly from the creation of the request itself -- to processing of the request -- simply hold down your Ctrl key while completing the request (in other words, while clicking on its "Save" button). On the basis of this variation, the system will take you right to the same item, as loaded into the PartsProcess form, for appropriate further processing.
If you happen to forget the above variation, just float your mousepointer over the form's "Save" button. A tooltip will appear for purpose of reminder:
A few improvements in the new SD-Rolodex:
Early adopters found a few small faults in the new Rolodex, which have been addressed in this release. Most significantly, I realized, for the two yellow Notes boxes that fit to the left, respectively, of the Companies and Persons lists, I'd initially forgotten to put in vertical scrollbars (in case you have lots of notes and need to scroll), and the ability to drag in hyperlinked objects. With the latter fix, you can now drag pictures, documents and files into either note box. As one example of such use, with respect to any company with whom you have a contract, I suspect you may want to drag in a hyperlink to that contract.
Improvement in the new SD-TimeClock function
A few weeks ago I overhauled ServiceDesk's TimeClock function, where your employees can punch-in and out on an electronic TimeCard. Afterwards, it became apparent I'd left out an important ability: to punch-in or out on the basis of an entered time, as opposed to the computer's system time. This can be needed, for example, if an employee forgets to punch-in on first arriving, and realizes it later in the day. To invoke the method, simply right-click on the applicable "Punch" button, rather than left-click (a ToolTip will remind you of this method if you simply float your mouse-pointer over).
A dialog then ensues for entry of the manual time -- and,
when it's inserted to the TimeCard, it's with a flag advertising that the time
was manually entered (this is to provide the owner/manager with a method of
policing, if the event that an In or Out time happens to become suspect).
Announcing . . . (drum roll please) . . . the SD-Rolodex !!!!!!
Though we recently acquired its maker, fact is we've been converting users from our former competitor's system, LogiSERV, for a long time. These "converts" to ServiceDesk have, of course, been very happy with their conversion -- with a particular and notable exception. Many have lamented the fact ServiceDesk has lacked its own equivalent to a Rolodex-type function that's long been built into LogiSERV. In fact, more than one former LogiSERV user has made it a point to periodically tell me their office continues to run LogiSERV, in the background (even while using ServiceDesk for main operations) -- solely for the sake of using its superb Rolodex.
With this release of ServiceDesk, finally, those users can turn off their old LogiSERV -- and stay exclusively in ServiceDesk.
Yes (and as previewed at the ASTI convention), we now have our own Rolodex-type function.
We are, furthermore, betting users will find our new Rolodex is structured with a far more rewarding, flexible and powerful interface as compared to LogiSERV's, or any surviving competitor's present equivalent. Here's what it looks like:
To bring up this new feature, you can click on File Functions in ServiceDesk's MainMenu and look down about nine items to the menu option titled Rolodex:
Either that, or directly use the suggested quick-key combo,
Shift-F3. Upon bringing up the new interface, please note there is a
button in its bottom-center area titled "open Mini-Manual." If
you click on that button, it will open a little five-page handbook (same as
via this link) that
provides all needed details regarding how to use this awesome new feature.
Internal "Pay for Performance" Reporting
Approximately one year ago, Whirlpool introduced a program (often abbreviated as "P4P") that financially rewards servicers if they meet a very simple set of metrics. Yesterday, a certain user suggested it would be helpful if servicers could analyze internally, to see how they are progressing on that precise set of metrics. Seemed very sensible, so we have a new report:
It is the very same set of metrics Whirlpool measures, but may be gleaned at any time you want from your internal, ServiceDesk data. This new report is available from within ServiceDesk's Reports form (F11). Simply go there, pick the 'Performance - Clients' radio button, then 'Pay for Performance.'
Technician Performance Reports -- Announcing . . . "The Mother of all Overhauls!"
You asked, we listened (okay, I was sloooowwwwww to listen, but I did).
We've long had a suite of "powerful" technician performance reports (five in all). They've been subject to occasional incremental improvements over the years, though nothing since their initial inception to (as my dad used to say) "write home about." Please notice, I put the word "powerful" in quotes. It's because these reports were drab, all textual, mono-color and with no graphics. Sure, they worked great if you happened to have the kind of mind that can look at a large quantity of raw numbers and easily divine real and substantive meaning from them -- but most minds don't work that way. So, not everyone celebrated these reports.
I took a first step toward major improvement with Rel. 4.4.43, just a while back. But that was tiny compared to what I've now accomplished. This release includes a true and major overhaul. It will produce tech-performance reports that, finally, are designed for the every man. The basic set of reports has not changed, nor has the data (with some few exceptions) that goes into them. What's really changed is the presentation.
Here, for example, is a Tech's-Revenue report as generated in SD Ver. 4.4.48:
And here is the very same report, Ver. 4.4.49 style:
As you can see, it's the same raw numbers at play, but the revised version presents them with a whole lot more pizzazz. And the pizzazz is much more than mere fluff. Color differences, between the first section and others, make much more intuitive the distinction between company-wide figures (i.e., "ALL" in the top section) and the figures in following sections that pertain to specific techs. The colorful and integrated graphs are even more powerful.
In such regard (and using this particular report as an example for potential analysis), please notice the four graphs in the top section provide company-wide (or ”par”) geometries for each key measure, and each tech's graph is purposely arranged to allow easy direct comparison. Glancing at the green graphs, for example, you can see that three of the techs in this report are performing well above-par in regard to total sales (CP looks particularly impressive). Their average totals-per-work-day (yellow graphs) mirror the same fact. However, one of the techs who's strong in total sales, is not so strong in average total-per-ticket (AV, blue graph).
The leftward purple/violet graph is particularly interesting in its ratio-type comparison between labor and materials sold. Glancing at this graph in AV's section may give an immediate clue as to why his average total-per-ticket is below par. It appears, simply, that in comparison to others he is underselling on parts. Perhaps that is all he needs to amend.
Anyhow, the general concept is that with the addition of such integrated graphs and other enhanced visual cuing, these reports can now be a joy to peruse, literally thrusting large elements of meaningful analysis into your brain (and at a mere glance), rather than making you toil to scavenge small elements of meaning.
All five reports in the Tech-Performance series (those reports in the F11-form and under that title) have been similarly upgraded, though the particular visual scheme in each is unique to its purposes. I urge you, please, explore these reports. I think you will be positively delighted by what you find. Please know, too, I have updated the corresponding On-Line Report-Handbook. There is a button to load this handbook in the bottom-right corner of the F11-form, but here also is a link. Discussion about these particular reports begins in that Handbook on page 14.
In regard to two of the upgraded reports (Technician Recall Rates, Unit-Info Method and Technician Recall Rates, Key-Word Method), I did much more than enhance the resulting visuals. In regard to those in particular, I totally re-did the underlying infrastructure. Formerly, these were reports that could take (depending on circumstances) a long, long, long time to run. They are now at least ten times faster. Better still, they're much more logical in their underlying methodology. I'm betting you're now going to be very fond of these reports. For details of what's different, please read in the appropriate section of that On-Line Reports-Handbook.
Now that we have truly outstanding visuals in regard to
these reports, I'm betting people are going to want corresponding upgrades
on other reports. Alas, my work never ends!
New "Report on Funds Deposited " now available in the FundsControl form:
A while back (see entry accompanying Rel. 4.4.7) we added a spiffy new report in the (Ctrl-F9) FundsControl form. Called the Reconcile Items Collected Report, its purpose is to summarize all items of money as ostensibly received (typically on the prior day) -- for the purpose of comparing to monies as actually found in hand, to assure you actually got all the monies you were supposed to.
With this release, we add a beautiful new companion report. As its title (indicated in this section's heading) suggests, its purpose is to provide a summary of all items that were ostensibly deposited to the bank, within any period (typically, we expect, it will be used on a daily or weekly basis). This can: (a) provide a simplified basis for you to enter the amount in your checking ledger; and (b) provide an added cross-check for comparison purposes.
Here is a basic image of the report:
With addition of this report, we had to once again do some re-arranging of the option-selections as initially presented in the FundsControl form. There are now, simply, too many options to place in the initial listing. Instead, two of the initially-presented options will bring up sub-menu options. The one as applicable to this report is logically titled "Deposit-related functions.
When you select that, you'll see the sub-options as follows:
Please note this is where to find the new report, and is also the place to now find the "Assemble Deposit" and "Confirm Deposit" functions, which used to be on the initial menu.
Keyboard-Based Upgrade
for New Checkoff-Status Methods in DispatchMap
It's very difficult to please everyone all the time. It's also true, we've found, that while new users sometimes complain about ServiceDesk being too keyboard-centric (i.e., not enough dependency on the mouse), whenever we make an established function depend more on the mouse, established users quickly lodge a loud chorus in protest.
This happened in regard to the enhanced Checkoff methods, as introduced in Ver. 4.4.45 (see third item in prior entry, as pertaining to that release). In response, I've done the following:
(a) With the list of Checkoff statuses displayed (standard means to invoke is by doing a Shift-Click on the item, within the tech's list of jobs, you want to check off), you can use your keyboard's Up and Down cursor keys to move the mousepointer from one item to the next.
(b) With the mousepointer over any particular item in the Checkoff list, you can hit Enter on your keyboard to make the selection.
(c) There's is also a new/alternate means to first display the Checkoff list. With the mousepointer over a tech's list-item job reference (yes, this particular mousepointer positioning you must do with the mouse), hit Shift-Enter on your keyboard.
Hopefully, these improvements will allow everyone (on both sides of the mouse-vs.-keyboard divide) to be happy.
I should mention (while simultaneously placing a pitch here for two of our major supplementary products), I somewhat resisted making the investment (it consumed a whole morning) programming this very minor tweak. It's because, those of you who are still doing manual check-offs for routine dispatch-related events, in my opinion, should not be!
Optimally, requests for confirmation and check-offs of confirmation should all be handled via automation as facilitated via SD-CyberOffice. When you use that system as intended, these check-offs occur automatically, without any per-item effort required by office personnel.
Similarly, confirmation of dispatching to the techs, check-offs of arrival and departure, and check-off of PVR status should, optimally, all occur via automation with the techs as facilitated by SD-Mobile. In my humble opinion, you should not be consuming separate resources to manually handle these mundane (albeit important) tasks. Automation is much smarter.
To put it another way, this improvement involved polishing
the edge on a tool which -- for the fully-advanced user -- has been largely
superseded regardless.
New
LG "GSFS" Claim Submission Format:
Effective on this date, LG has ended its former "CLS" integration system (which provided direct integration, between servicers and themselves, on both dispatch processes and claims) -- in favor of a new system called "GSFS." It's our understanding they have also ended integration via ServiceBench. Most alarmingly, their new system has no "handles" to facilitate the direct integrations (for dispatch processes and direct claims transmission) that were formerly enjoyed. In fact, all that is available now, for integration (at least as we understand it), is the ability for you to upload claims via the old-fashioned file/batch-upload method -- though as connected to the new GSFS system (i.e., SD puts the claim information into a file, and you have to separately upload it via login to the GSFS website).
We don't know anyone that's happy with this, but (and at the least) here at Rossware we've provided you with a "just-in-time" update to facilitate claims creation in LG's new format. Assuming you make your first GSFS claims on the morning of Monday the 4th, we believe it will work. Our output has been tested with LG, and verified to be in the correct format.
New
Samsung Claim Submission Format:
So long as I was busy creating a new claim submission format for LG, I figured I might as well tackle another item on my long, long, long list of projects -- which was to create a submission format for Samsung (in case it's not obvious to you, every claim processing entity has its own format into which claim data must be forced; each format is unique, and it requires a lot of program coding to make the data conform perfectly to each).
In regard to this newly-added format for Samsung, I'm considerably less certain you'll enjoy immediate claim-submission success. Samsung's documentation (detailing what's expected for their format) is very sparse in regard to a number of the needed fields -- leaving considerable ambiguity in terms of what must placed where. I suspect further finessing will be required before we reach total success. This finessing will likely depend on feedback from you (we've had no direct testing with Samsung, such as we have indeed had with LG). I encourage you to use the on-screen NARDA's "Translation Tips" to see how, specifically, we are presently translating boxes from the NARDA into Samsung's claim format. Again, I'll look forward to your feedback.
Enhanced
Appointment-Check-Off Scheme in DispatchMap -- Including New
JobHasBeenPreScreened and
JobHasBeenPostScreened CheckOffs:
Evolution is not always the best designer. Way back in the early days of the DispatchMap, we realized it would be good to have a "Check-Off" there -- to visually indicate, in respect to an appointment, if it had been dispatched to the tech (i.e., actually given to him, so it was known that he had it). We used an actual check-mark symbol for this purpose, and a simple Shift/Click action as the means for toggling an appointment to show it with check-mark, or not.
That was terrific, except we soon realized it would be nice to have a somewhat similar (but different) action and symbol to indicate the tech had actually arrived at an appointment, and another to indicate he'd finished there. So, we made added key/mouse-click combinations for these purposes (Ctrl/Click and Alt/Click), along with added associated symbols.
That wasn't too bad: three different (and simple) key/mouse-click combinations, and three different associated symbols. But if it's good to have indicators for those statuses, isn't it better to have indicators for more?
What about showing, for example, if an appointment's PVR was done. Hmmm. That means another symbol (or symbols), and another key/mouse-click combination to toggle. Now, with the simple key/mouse-click combinations already used, we had to resort to a more complex combination. We chose Ctrl-Alt/Click.
Still, a good concept can't quit growing. Before long, someone suggested it would be good to have a check-off action to show a customer had been contacted (typically the evening prior) to confirm their expectation of the next day's appointment. So, we added a "Confirmed-With-Customer" check-off (Shift-Ctrl/Click). Then, as people began using that, they realized it would be good to have a different check-off to indicate confirmation had been sought (i.e.,. voice message left by telephone, email request sent, CyberOffice processes initiated, etc.). We used Shift-Alt/Click.
Finally, someone suggested it would be good to check-off to indicate the tech had arrived on a job, only to face a "No-Show" by the customer (Shift-Ctrl-Alt/Click).
As you may gather, it reached the point where we'd used all the potential key/mouse-click combinations (see illustration of old DispatchMap Cheat-Sheet, about a page-down below), and if a user was interested in doing any of the check-offs manually (in truth, the need for this was typically limited by the fact many check-offs occur via automated means), it was a confusing combination of key/mouse-click combinations to remember. There was of course an always-on-hand, easy-to-instantly access cheat-sheet to remind, but still, the inelegance of all those combinations was undeniable.
And, wouldn't you know it, people eventually wanted still more check-offs.
In particular, many companies have a person who advance screens each appointment, seeking to predict if particular parts are likely to be needed (intending to send the tech out with such parts, if so). Some such companies asked for a check-off to indicate when such "pre-screening" had been performed.
Many other companies do what might be called "post-screening." That is, periodically throughout each day, someone in the office scans the DispatchMap looking for jobs on which the PVR has been done, but on which the job is not yet complete (i.e., those showing with a circle-X symbol). That person opens the JobRecord, and immediately orders the parts -- which, presumably, the technician requested. This is a rather brilliant practice, because it shortens completion times, and impresses the heck out of your customers. Anyhow, these companies asked for a "this-job-has-been-post-screened" check-off.
As noted, we'd already used all possible key-modifier combinations (as potentially combined with a left mouse-click; right mouse-clicks are used for other things) -- so there was a clear need to change our methods -- if we were going to accommodate such added check-offs.
What I've done is to eliminate all items in that former zoo of key/mouse-click combinations -- except the initial and original one: the simple Shift/Click. Now, when you want to toggle any check-off status on any appointment (in all cases, we're referring to its list reference under the tech to whom it's assigned), do a simple Shift/Click. In result, the system will display a list of all possible check-offs, and you simply must do one more click to pick the one wanted.
Please note that any appointment's existing check-off status will show in the list with a line through it. If you want to un-toggle that check-off (i.e, put the appointment back into a check-off status of nothing), click on the lined-through listing.
Besides the fact you can now use those two new check-off statuses, there is obviously much added simplicity. The DispatchMap's contextual Cheat-Sheet (right-click in any empty space to bring it up) reflects this.
Old DispatchMap Cheat-Sheet | New DispatchMap Cheat-Sheet |
![]() |
![]() |
In our view, a shorter Cheat-Sheet (that nevertheless accommodates more functions) is an improvement indeed.
Please note, if you're using SD-Mobile, it's important with this update to also
update SD-MobileLink to Ver 1.3.33 or above. Prior versions will not know
what to make of the new check-off statuses.
WageReport Updated to
Work with New TimeCard structure:
As mentioned in the prior entry, we
updated the TimeCard structure, but had not yet updated the WageReport
to work with the new structure. This created a brief window of time (turns
out it was just two days) in which you could not run wage reports.
This release fixes that (i.e., you can again run the reports, and they should
work perfectly with the new data structure).
Changed
Nomenclature for the Problem Customer Advisory:
The Problem Customer Advisory (Alt-F11) no longer exists -- at least, not under that name. Turns out, we discovered, many people were using this tool to notate situations with customers who were not "problems." In particular, the tool was sometimes being used to denote customers who were VIPs, and deserving of special, red-carpet treatment. Given such broader use, we decided the name of the tool needed changing. Thus, it's name is now the Special Situations Advisory. You should feel free to use it in connection with any customer that needs to be flagged for something special or unusual in their regard.
Upgraded TimeClock System:
The TimeClock function in ServiceDesk (via which employees may Punch-In and Punch-Out on electronic time cards) is one of its oldest functions, and had received virtually no modernization over the space of many years. In the meantime, upon creating a complimentary TimeClock function in SD-Mobile (a year or so ago), we deemed the data-format as used by the SD-TimeClock system too archaic, and so designed Mobile's system with an improved, more modern structure. In result, we had two incompatible TimeCard structures. SD's WageReport continued to work with the old format, while if you wanted to do WageReports for techs using Mobile's TimeCard, you had to open that data in Excel and do some manual work there. It was a situation crying for correction, and this release gets us almost there (the next release will complete the process).
Specifically, with this release ServiceDesk itself switches to use of the same modernized data structure, for each employee's electronic TimeCard, as SD-Mobile has been using for the last year or so. Upon first punching In or Out for any employee, the system will automatically convert that person's TimeCard file from old format to new (more specifically, a new file is made in the new format, with filename TimeClock.xx.TXT [where "xx" is the employee's two-letter abbreviation], and the old file is changed by appending the word ".OLD" to its name [thus changing, for example, TimeLog.xx to TimeLog.xx.Old]). All future punch Ins and Outs will now be done to the new files in the new data format.
The TimeClock form itself has also been substantially improved, for better overall appearance and functionality.
Old Form Interface | New/Improved Form Interface |
![]() |
![]() |
Please note the improved simplicity of now having only two buttons, and it's only the button that reflects the expected action that's enabled (in prior design, the "Okay" button did double duty for both actions, depending on the circumstance -- which sometimes led to be people getting off-synch, thinking they were punching In when punching Out, and vice versa). The new system also has a much improved method for coping with a forgotten prior-punch event (e.g., I need to punch In this morning, but it turns out I forgot punch Out last night, or vice versa). The old system would permit the present needed punch (via its bottom-center button), while leaving as unresolved the prior (and forgotten) opposite punch. With the new system, even though the unexpected of the two buttons appears to be disabled ("punch IN" in the above example) it will still accept a click. If you click on the disabled button, it invokes a dialog where a forgotten "punch" event can be manually provided. In this event the TimeCard file is appropriately marked to indicate that that punch was input manually (thus, as a manager you can know to potentially consider that punch as suspect).
There is one further element of work we did not get to with this release, and that is the WageReport. It has not yet been re-written to work with the new data format. We'll do another release, very shortly, that has that improvement.
Improved Performance Analysis Reports:
It was, in fact, our effort to improve the overall set of reports as available in the F11 form that led to upgrading the TimeClock system, as above-described. Specifically, upon having made several other reporting improvements, I reached the point where I wanted to add a new report to provide specific comparisons between time spent on jobs by a tech as compared to time on-the-clock. To do this, I needed to finally unify SD's internal TimeCard use with what's in Mobile -- which led to the above-described changes. Prior to reaching that point, however, I'd already made several improvements.
In particular, all of the performance reports have been upgraded in some degree. There are presently six such reports overall. Two under "Performance -- Clients," and four more under "Performance -- Techs" (the illustration shows only the two headings, which must be clicked to see the lists of respective reports from which to choose).
In several of the reports, overall appearance has been changed for
improved readability and understanding. In some cases, new figures have
been added and/or tweaked. In all cases, we have added an "Export
Check Data" function. It's a new button that will appear (to the
lower-right within the form) as the report displays. If you click on the
button, it will create an export file that contains elements of data as relevant
to compilation of the report in question. It will even offer to open the
file for you (typically in Excel). The purpose is to permit you -- if you
have any questions about how the report figures resulted or as to their
reliability -- to look at the actual data that produced those figures. You
may, if you like, to further analysis on their basis as well.
Improved Updating of ServiceDesk:
Until now, there's been a significant potential nuisance when updating ServiceDesk. It arises if you're installed in thin-client mode, meaning a setup where several stations operate from a single SD installation. The difficulty is that the SD program file can't be replaced with the intended newer copy (Windows will not permit it) so long as ServiceDesk is running from any station that depends on that instance of the program file. Thus, it's always been necessary to close ServiceDesk at any and all stations that may be running from the instance of the program file one is attempting to replace. Particularly for large operations (i.e., with many stations) this necessity has sometimes posed a nuisance.
Our favorite geek here at Rossware, Matt, came up with a solution. Turns out, while Windows will not permit you to remove or replace a program file that's in-use, it will (at least on those systems where we've tested it) permit you to re-name the file. So, we've now re-programmed the little ServiceDeskUpdaterX utility to perform some behind-the-scenes sleight-of-hand." This is, essentially, the utility that opens the Winzip Self-Excractor update file after ServiceDesk closes following the update download, and re-opens ServiceDesk after the unzip. The new version of this utility does more. Behind the scenes (and without you even needing to be aware) it re-names the ServiceDesk program file (specifically, to "servdesk_temp.exe"). Thus, when the Winzip Self-Extractor seeks to replace the normal ServiceDesk program file ("servdesk.exe"), there is no objection from Windows because a file by that name is no longer there, and in the way. After the unzip, the temporarily re-named old file is deleted (no objection from Windows, since it's not the file that's being run from). We're pretty sure Microsoft did not intend to permit this loophole through which we're wriggling, but it seems to work regardless.
You will need a new copy of the ServiceDeskUpdaterX utility to take advantage of this improvement. It cannot be included in the standard download/update file -- by reason of the fact it's the very utility that must be running to facilitate opening of that standard download (and thus would be in the way of its own replacement). However, if you watch the dialog upon doing your next update (i.e., the next one after this one), it will coach you through this replacement. Either that, or do it directly now by downloading "Updater Utilities" from the ServiceDesk downloads page.
New "Customer's PO-Number" Field Added to
ScheduleJobsReport-Type3 Export:
Password Protection (as
described in first-preceding entry below) extended upon:
Password
Protection When Changing Tech on Appointment Where Prior Assignment was Definite:
The caption pretty much says it. Until now, if in the
DispatchMap you wanted to change the tech assigned on a particular appointment,
the system would simply warn
you if the prior assignment had been marked as "Definite." It would not
prohibit the action.
Now, besides a warning, it will optionally require provision of a password
before allowing you to proceed. The default setting for this password
protection is "ON" -- meaning, if that's your preference, just leave it as is.
If your preference is against having the password protection turned on, you'll
need to go the Security form and turn it off.
FYI, the immediate impetus in creating this was the need
expressed by a company in
In this regard, there is a connected/added new feature.
To make the solution effective for the
We don't think picking Definite as the default will be optimum
for any companies except those few that pursue practices such as the one in
Dramatically-Improved Integration with Mobile Tickets:
We have now completed a massive upgrade of Ticket/Invoice management within the Mobile context (includes features such as "Previewing and Editing, Separate Saves, Re-Loading Prior (and Appending with Present), Save-Same or Save-New," etc.). The Mobile-side elements are described, in depth, in the most recent entry of SD-Mobile WorkDiary, and we encourage you read there, for full understanding.
On the ServiceDesk side (and as announced a couple of releases back), there's a new Mobile form, as one of the options within the FinishedForms (Alt-F4) context. It can be used to review any/all tickets as created within the Mobile context, to revise them for re-use by Mobile, and even to create new tickets, in house, for use by the tech when he goes out later on a job.
New form option in Alt-F4 | User picks which of multiple saves should be loaded |
![]() |
![]() |
Perhaps most usefully, the new FinishedForms Mobile ticket can be used to facilitate making a SaleJournal entry, direct from the Mobile ticket -- eliminating any and all need for an operator to re-type figures as already created by the tech in the field.
There are two small caveats, in regard to this ServiceDesk-side use:
One is that, unlike the other FinishedForms, the new Mobile one does not presently offer to import data (into its various boxes) from underlying ServiceDesk data (as do the other forms).
The second caveat concerns a matter of slight ambiguity, when using the Mobile ticket to populate a SalesJournal entry. It's a question of which of its summation figures (Parts-Total, Labor, Other, Sales-Tax and Total-Ticket) get translated (aka "mapped") into which fields of the offered entry. In particular, while the Mobile ticket has a Labor and an Other field, the SalesJournal entry has a ServiceCall and OtherLabor field. It's not necessarily obvious how these fields, with their disparate labeling, should correspond. The answer is, (as presently programmed) they feed in the sequence as just recited. If you need different "mapping," please let us know.
A tiny further caveat is that versions of SD-Mobile prior to 1.3.18 did not include a dedicated InvoiceNumber field, and in consequence will not show up via this new path in ServiceDesk. In other words, any Mobile ticket created in Mobile Ver. 1.1.17 or older will not be offered for you an SD Mobile ticket.
Improved Scaling in SD Interface:
Though Windows is a nice environment
to program in, not everything is perfectly easy. With ServiceDesk's layout
in particular, it's been a challenge to make sure the four Callsheets
consistently fit with perfection within the framed space. What makes it
difficult is, depending on preference settings in Windows, the thickness of the
surrounding border can vary, as can the caption bar height, and also menu
height. If all were known and constant, it would be easy to set an
external size that would perfectly accommodate interior elements, with
confidence all would consistently fit. But the sizes vary, and it's a
matter we've somewhat struggled with (in result, you may or may not have noticed
imperfect fits of the Callsheets within their spaces). With this release,
I think we've got it perfect, and you'll likely see the Callsheets fitting
perfectly in place, regardless of your preference settings.
Now a Second/Alternate Whirlpool/ServiceBench Warranty-Entitlement Inquiry:
Six weeks ago (and amid significant fanfare) we introduced a near-instantaneous, single-click method for obtaining a warranty-entitlement and product-history report, on virtually any Whirlpool Corporation-related product. A short time later, we added the same capability, for techs, in SD-Mobile. In either context, it's great -- albeit subject to a small limitation. The entitlement info, as provided by the standard inquiry, is less detailed than may sometimes be wanted, particularly with respect to extended warranties.
To address that limitation, we've now added a second inquiry. Access to this new function, like the original, is via a button on any applicable UIS sheet (i.e., within the UnitInfo form). In fact, we've now fit both buttons into the same space as the original:
Old Button Arrangement | New Button Arrangement |
![]() |
![]() |
As you can see, we've also colored the buttons, to more effectively distinguish them from others on the form. Please go ahead and try the new button (it's the one labeled "SB Web Inquiry"). Be sure to do it on a UIS that involves a Whirlpool-related product. You'll see it opens a very nice web-page that contains a lot of entitlement-related data. Unlike the other inquiry, however, there is no product history. It seems that no matter what (and like the saying goes), you just can't have your cake and eat it too.
Special-Order Parts Management -- A Dramatically Improved Manual Section:
Do you ever have to write something, and you just can't figure out how to do it?
That was the case with me, some ten years ago, when I first wrote the manual's section describing how to use the Special-Order PartsProcess system. I knew how it worked, but for some reason could not think of a good strategy for communicating my understanding. In the absence of a better solution, I settled on a description I always knew was lousy. And, I apologize. I think many users have had a tougher time, getting the essence of how to use that element in the system -- than they otherwise would have -- if I'd managed a better description.
The good news is, I finally did it. Though many times (in the intervening years since) I've wanted to do the re-do, it was not until now that I mustered the energy, time and vision to finally make it right. I think the new section does a very nice job. It will be found, contextually, in future publications of the manual, but you can also access it as just an excerpt, right now. I've added a button for the purpose in the top-left corner of the PartsProcess form:
Or, if you want to check out the new section without first
going into ServiceDesk,
here's a direct link.
New: Ability to Open -- and Edit -- SD-Mobile Tickets in SD:
For details on this,
please see entry in SD-Mobile WorkDiary.
ANOTHER MAJOR DRUM
Single-Click
Parts Inquiry and Pricing -- via
Revolutionary MyPartsHelp Service:
Here at Rossware, it's
our goal to do stupendous things, and on a frequent basis.
Usually, we do pretty well via offerings produced totally 'in house.'
Sometimes, however, the most awesome stuff involves partnering with
others.
Within the last year,
for example, we partnered with Merchant Warehouse for integrated credit
card processing, then with Whirlpool/ServiceBench to provide single-click warranty entitlement and product history reports.
With this release, we
announce a new partnership -- with possibly the most awesome result yet.
For background, over
the last year a group of your peers (other retail-level servicers) pooled their
financial resources to develop a new technology, and a new company to manage it.
The company is Service Company Solutions, LLC.
The technology is called
MyPartsHelp.
What does MyPartsHelp
do?
Quite simply, it links
with ServiceDesk, and on the basis of a single click connects to each of your
preferred vendors to inquire about pricing and availability on a given part
(i.e., the part you clicked on, within ServiceDesk).
It displays the result back to you inside of about one second.
Really, you won't believe how effective it is, until trying it.
For each vendor, it not
only shows if they have it; it shows how many they have, and at each of their
locations. And it's not the
vendor's standard/published price that's shown; it's your own particular account
price. That's not, remotely, all.
Another click (and just
a couple seconds more) shows you
nationwide availability on the part.
It does so by polling vendors from around the country.
You won't believe how often you're able to find NLA parts or someone
who's stocking an otherwise backordered item -- with just two clicks, and less
than five seconds wait time.
But it gets better
still (do I sound like one of those TV ads?).
You likely know about
RepairClinic.com, and how when you lookup a part on that website you're
instantly provided with a set of very clear photos showing the part from several
angles (dramatically helps to reduce mis-orders).
Guess what. That same set of
photos shows (along with everything else) in the MyPartsHelp, single-click
lookup. On top of that, as one of
your MyPartHelp membership benefits, you can order those
can't-possibly-get-anywhere-else parts at 15 percent off the price everyone else
must pay.
Do I sound like I'm
excited to announce this product?
I am (and, as in a few
other instances, I apologize to those of you who are in fields other than
appliances).
On top of all the other
good news, the MyPartsHelp service is downright cheap (about $20/month).
Even better than that, it costs nothing to try (also, in a while it may
also be available in the electronics field, and after that, who knows?).
Oh, and did I say there's more?
There is. Right now you have the opportunity to get in on the ground floor. For a brief time only, MyPartsHelp accounts are being offered in beta (which is why the pricing is presently so low). Features are great already, but are destined to grow, and pricing may too. I suggest getting in while it's cheap.
To begin usage, you can go to this website:
http://mypartshelp.com/public/
Or, better yet, let ServiceDesk take you there. For this purpose, open your ServiceDesk PartsProcess form (Ctrl-F8), and right-click in the colorful label area at top to display its contextual "CheatSheet:"
Now pick the menu option labeled "MyPartsHelp Setup." This produces an option where you can choose either to link to the MyPartsHelp account setup page, or to enter your MyPartsHelp login credentials. First, of course, you'll need to do the account setup (after all, you'll have no login credentials until you do). After that's done, go back to the same venue -- only this time choose to enter your login credentials. Now, pat yourself on the back, and say Hurrah, because you're ready to use MyPartsHelp.
Actual use could not be more simple, or require less work.
Just do the normal stuff, that you'd normally do, within the ServiceDesk PartsProcess form (i.e., responding to internal requests to acquire parts that are not stocked, as displayed for you via line-item listings within that form). Only, when you're looking at any particular line-item (and with part number already determined and inserted), don't go to a vendor's website to ascertain availability and price. Don't call. Don't email or fax an inquiry. Instead, just do a simple Ctrl/Right-Click on the part number.
That's all it takes, and -- inside of a second -- you'll see the magical result!
Please notice, among other things, only Automatic Appliance has this part in stock -- a fact MyPartsHelp reveals inside of a second -- instead of forcing you to spend who-knows-how-much time making who-knows-how-many-telephone calls otherwise seeking to find it. Please notice, further, there's a "Nationwide Search" button in the top-right corner; if the initial display had not shown any vendor stocking it, the Nationwide Search would stand a good chance, still, of doing so. Finally, please notice it's only for your preferred-setup vendors that the system displays cost; MyPartsHelp is intended as a lookup tool only -- not as a price-shopping tool.
Assuming you're an appliance servicer, please, do not fail to
do this. I feel certain you will
love the service. It's going to be
great for your business.
New Sharing of Merchant Credentials for Virtual Terminal:
Hopefully, you are using the Virtual Terminal feature (internal credit card processing) that was added (both in ServiceDesk itself and SD-Mobile) many months back. If not, be assured that you should be using it. It will save you money, directly, via reduced merchant fees. It will save you, indirectly via reduced time in conducting transactions, and because of increased accuracy resulting from its direct integration with other processes. It will also make it just a lot more fun, convenient and easy to conduct credit card transactions.
As one element in that system's design, we made it so each station in ServiceDesk could be configured with a different set of merchant credentials. This was, in particular, to accomodate the situation where you may want to use a different merchant account at different SD stations. However, that's certainly not the typical case. For most users, it's nice to have the same credentials setup at every station, and a nuisance to have to individually enter at each
With this release, that nuisance is
eliminated. When the user at one station saves credentials, the system
offers to make the same credentials available to other stations. From the
point forward, if at another station you even click in a box to begin entering
credentials, the system will offer to insert the other-saved credentials for
you. By this means, we preserve the potential to have unique credentials
at particular staions, if wanted, while simultaneously making it much easier to
enter the same set at each station, if that is preferred.
New MyCriteria Feature allows you to create your own Add-On-Info Template for Callsheets and JobRecords:
A few releases back (with Ver. 4.4.24) we announced improved formatting in the general Callsheet/JobRecord interface. Among other things, a new button was added:
We explained that, though this new button did not yet have a function -- in fact, the whole design improvement had been undertaken for the very purpose of accommodating it (or, more accurately, the function it would ultimately fulfill). We promised to create that new function soon (i.e., to give the new button its purpose).
That promise is fulfilled with this release.
Rather than taking space, here,
to describe details, we'll instead link you to a
new little Handbook that
describes both purpose and implementation. The purpose is described on its
first page. If it's not a purpose you want to pursue, that's all you'll
need to read.
MAJOR DRUM ROLL PLEASE . . .
Single-Click Service Entitlement and
Product History Inquiries via ServiceBench:
For the last three months, or so, there's been a new (but inoperative) button in the UnitInfo (Shift-F12) form. It's been there, with ready-to-go machinery that's designed to let you request -- with a single click -- service entitlement and product history from ServiceBench -- specifically, as connected to any products fitting under the Whirlpool umbrella (e.g., Whirlpool, KitchenAid, Maytag, etc.). We've been waiting, essentially, for the "switch" to be turned on at ServiceBench.
The great news: as of the Tuesday morning, 9/15/09, that switch is turned on!
Now, in the ServiceDesk UnitInfo form, that new button is NOT inoperative any more:
Try it. So long as you have a valid Whirlpool account as registered with ServiceBench (and assuming you click on this new button when an appropriate Whirlpool-family product is displayed), you'll quickly get a response from ServiceBench, giving you beautiful information. The UnitInfo form expands vertically to display it for you, as follows:
Is this hot, or what?
For those of you who are in fact Whirlpool servicers, may I suggest giving great thanks to your Whirlpool rep for the fact Whirlpool worked behind the scenes, with ServiceBench, to make this great capability available.
Further improvements in Archived-PartsProcess, including a New PO-Number Search:
In conjunction with the last set of improvements (see prior entry, first-item below), we'd intended to add a new search option to the Ctrl-F8 archived-PartsProcess environment: a search on your own purchase order number. Sadly, we discovered this particular element of data was not being saved in the archive -- a matter that had to be addressed before a meaningful search could be created. That is done with this release -- meaning that new search is now also available:
While we were at it, we improved editing in this context a bit more. In particular, when you click on an item to edit (and then the edit boxes display), the boxes that are not going to permit an edit will show in grey rather than white, providing an on-its-face indication of non-editability.
As with the last entry, please
note there is also a
caveat here. The searches on your own purchase order numbers will only
work for items archived after this update.
Improved Editing in Archived-PartsProcess Records:
By their nature, archived records are usually at least somewhat resistant to editing. This is because we deliberately pack the data tight, to minimize resource usage. Even so, it's been our practice to expand editing opportunities when users express a demand for it. In this regard, editing is now more available -- as compared to before -- in the Ctrl-F8 archived-PartsProcess context. Regardless of how many characters were there when archived, you'll always have at least 50 characters of space available in the Notes section, at least 16 in the PartNumber section, and at least 16 in the PurchaseInvoiceNumber section. Additionally, any of the date and/or numeric fields will be fully editable (at least, assuming you're appropriately using a numeric or date value).
Please note there is one small
caveat. The extra space for editing will apply only to items as archived
after you've made this update. In other words, older-archived items
are still packed as tightly as before, and will not offer the extra edit space.
Small change in DispatchMap's DispatchOptions menu:
There's long been an option in the DispatchMap's DispatchOptions menu that produces, for applicable jobs, essentially the same output as offered directly via a JobRecord's PrintOptions menu -- and (for the latter) under the title "Job Description/Report." However, labeling for that option in the DispatchMap was not remotely similar. We realized it would aid clarity if it was. So, it's been changed in the DispatchMap's DispatchOptions as follows:
Old item description | New item description |
![]() |
![]() |
As you'll note, the quick-key
letter for this option has been changed from "F" to "J" (please pay attention if
you've been using "F"). Also, the option has increased power.
It used to be, when you picked the option and the SelectPrinter dialog box came
up, there was no option (i.e., from within that box) to choose email. Now
there is.
New "Parts-Window" Mode:
Since (basically) forever, ServiceDesk has had a "Tech-Window" mode. It's a mode into which you can put ServiceDesk that's designed to limit its interface only to those locales that you're likely to want a technician to access (PostVisitReports, JobHistory searches, etc.). You can place it in this mode by hitting Alt-W on your keyboard (think "W" for Window), or, from the Settings form, you can even specify that a particular station will automatically go into such a mode immediately upon startup:
Recently, we've had some users that wanted to limit the SD interface, at certain stations, to just those ServiceDesk interfaces that relate to parts management. So, we've created a new special-Window mode for that purpose (it's called, aptly enough, "Parts-Window" mode).
As you can see below, we've now modified the Settings form so that you can (if desired) make a choice between having a station auto-start itself in Tech-Window mode or Parts-Window mode, if either happens to fit your need.
Likewise, you'll notice that now if you hit Alt-W on your keyboard, you'll get a choice as to the type of restricted mode you wish to enter.
Just like in the Tech-Window mode, the new Parts-Window mode requires use of a password if the user wishes to exit back into the full ServiceDesk interface.
Substantially Upgraded Interface for Callsheets and JobRecords, Combined with New Button for Expanded Future Capability:
Over the years I've received a number of requests for the ability to attach various kinds of added information to Callsheets (of course with expected carry-through, of such info, to the JobRecords that result from them). There have been so many different requests -- for so many different kinds of added information -- that, to individually accommodate all that's been asked for, we could potentially have a Callsheet (and associated JobRecord) design that is three times as large and with ten times as many boxes in it. Since that, of course, is not practical, I have sought another solution. I've decided the general strategy will be to allow customization of input (i.e., you design the added info you want) as triggered by a single new button on these forms.
First step in going down this path was to assure I could artfully accommodate that new button (these forms are already pretty crowded, after all). I began experimenting, and one thing led to another. Via a little re-arranging, I accommodated the new button nicely, and (I believe) improved organization overall.
Old Callsheet Segment |
New Callsheet Segment |
|
|
As you'll note, the new button (bottom-right) is labeled "Criteria." It is not yet functional. That's another step down the road.
Also, the old MoreInfo button, instead of being labeled "Empty" when no contents are present (and "Yes" when there are some), is instead merely labeled "Notes" (just as before, however, it will turn a "warm pink" when contents are present).
Aside from the new button, notice that origin information is now at the top, which is a bit more logical than having it near the bottom.
JobRecords are changed somewhat similarly.
Old JobRecord Segment |
New JobRecord Segment |
|
|
While I was in the process of doctoring these aesthetics and organization, it occurred to me I might improve the visual cues as involved in a page of Callsheets that involves one or more Callsheets not-yet-used, one that is not-yet-used but has the Windows focus (and therefore is primed for use), and perhaps one or more that are used. By "visual cues," I mean making more intuitively obvious the distinction between these varying Callsheet states. You'll see the result after updating, and I'll not comment further here.
New export provided in ExportCustomerData form, new Handbook about exports, etc:
Over the years I've been very amenable to creating new exports for particular items of data, whenever something new was wanted. In result, ServiceDesk offers a ton of exports, with interfaces (to access them) spread contextually over a multitude of areas. There are so many that even I can lose track, particularly in regard to knowing what are the detailed fields that each export offers.
Recently we had a request from Whirlpool-NarSouth (it's Whirlpool's Latin America division) for several added fields as connected with an export they've been using. They did not identify the particular export, and the only other basis I had to determine which was by running a bunch of exports to see which matched, or by looking laboriously in my program code. Neither was an attractive solution, so I decided better clarity into the exports picture was needed.
To that end, I've created another little "Handbook." If you've not noticed, I've grown rather fond of these in the last couple of years. They're simple little documents that describe a particular area of interest, and can be contextually opened from places within Rossware programs, as needed.
This handbook is called, simply, Exports as Provided in ServiceDesk. As you can see, a simple click (on the link here) will open it for you.
Once having that little handbook assembled, I could easily see that the export in present use by Whirlpool-NarSouth was the ScheduledJobsReport-Type1, as accessed via the ExportCustomerData form (Alt-F3). Given that that export was working well for those employing it, I decided to leave it alone, and create a new export called ScheduledJobsReport-Type3. If you check the handbook, you'll see this new export has "really a lot" of fields -- so many it can be employed for all kinds of fun analysis, if you're so inclined.
While I was at it, I made several other improvements in the ExportCustomerData form, including substitution of the former 'Exit' button (who needs that?), with a button to load that new little handbook:
Segment from right-side old form | Segment from right-side new form |
|
|
If you run the new export right with this release, you'll find that three of the new fields are not yet functional. That should be addressed soon.
New integration with DealerInventory via as-you-type dropdown in POS context:
This is for those servicers who are also dealers, and using our SD-Dealer serialized inventory control program. Until now, when you were selling dealer items and using the ServiceDesk POS to do it, the method for inserting items to the POS form (e.g., I'm selling a refrigerator) was to select the items (as being sold) via the SD-Dealer interface, then in the ServiceDesk POS do a keyboard Alt-D function (think 'D' as in Dealer). This would insert, to be sold, each of the items you'd selected.
That old method still works, but there's a new one now.
When, in the POS interface, you click into any box in the part-number/model-number column, and when the little 'Integrate input from' box comes up, go ahead and select "Serialized Inventory."
Next, just begin typing any model number (as exists within your inventory) into the part-number/model-number column. You'll see a dropdown, as illustrated here.
Select from the dropdown just as you would if picking a part from the internal parts inventory or SmartParts dropdowns. You'll get an insertion, just as nice.
New Search Functions in archived-PartsProcess form:
Prior to this release, the menu options in the archived PartsProcess form (Ctrl-F8) looked like this:
We had requests for a couple of new search capabilities -- specifically, to search via Vendor-Invoice-Number and Vendor-Name. To accommodate this, we re-arranged the menu, as follows:
As you can see, the new search methods have been added near the middle. There has been a little other re-arranging as well, and some of the QuickKeys have been changed to accommodate the new lineup (for example, a Customer-Name search is now "C" rather than "N"). Please pay attention if you're accustomed to using the QuickKeys on any item now changed (we know, you'll have to do some adjusting, but sometimes that's the price of progress).
Of particular note is the fact old items 1 and 2 are now
gone (for specific-page choices, only "Last page" remains). We figured
those were little (if at all) used options, and the first page can still be
quickly accessed simply by picking "Last page," then using the Windows universal
First-Page command (Ctrl-Home).
New Fields in DispatchMap's ScheduleList Export Functions:
For some time there have been exports available from the DispatchMap for basic schedule information. Just display the map for any not-in-the-past day of interest, then hit Alt-P on your keyboard. In response, you get this set of options:
The two as circled are self-explanatory, and have been used by some servicers to create a list which then feeds into an auto-dialer program to automatically telephone customers with an electronic voice (sometimes called "robo-calling") to remind them about the next day's appointments. One difficulty for such users has been that ServiceDesk format for indicating an appointment (e.g., "31 MON 2-5") is not easily translated, to voice, by robo-calling programs.
To be candid, we've felt slightly reluctant to help with this -- based on conviction that our CyberOffice method of reminding is infinitely more modern and efficient.
However (and following Burger King's "Have it your way" motto) we believe in accommodating whatever methods of operation our clients choose (at least mostly). For that reason, we've added three new fields to the above-exports, as illustrated here:
To again emphasize, we think you'll be much better off using CyberOffice to confirm your appointments, but if you insist on using a robo-caller, these new fields should help.
New "Print-Job-Label/Sticker" Function:
A new user (thank you Jeff, at Intrepid) asked for a function that would print a Dymo-type label for attaching to merchandise that's in the shop for repair. It seemed logical to add this to the set of options as offered via the 'Print Options' button in the (F7) current JobRecords form. In fact, we needed to do an overhaul in that option set regardless.
The reason is, among the existing "print" options, there was one to print a Job-Description/Report, and another to email the same. Though differing only in respect to where the text went (i.e., printer vs. email), the two options were (illogically) not even next-to one another in the list of choices. On top of that, there was no longer a logical need to have the emailing option as a separate item. This is because, since it was placed there, we'd developed a more uniform method of offering to email an otherwise printable item, as opposed to sending it to the printer. This new method is via the PrinterSelect form itself (see entry accompanying release 4.3.97 for info on how and when this form was enhanced to allow such flexibility).
Give the above, we've now changed the old set of options, which looked this:
to a somewhat different set, looking now like this:
As you can see, the email option slot is replaced with the option for the new feature (which, really, is what this Diary entry primarily announces). Now, if you wish to email a Job-Description/Report, you'll pick the general Job-Description/Report option, then, in the resulting PrinterSelect box, just indicate that emailing is the method you want to use.
Now, about the new Print-Job-Label/Sticker feature:
It's configured solely for the Dymo 30252 label, as printed from a Dymo printer. That's all you have to know. Aside from that, just use it.
New "ScheduleList-Archive" Export:
There's an interface few people ever use. It's
called the ScheduleList-Archive form. It is available under the 'Dispatch
Operations' heading on the MainMenu (i.e., no quickkey). In the very
early days of ServiceDesk this form had significant use, but other and better
functions have relegated it to near uselessness. Nevertheless, we recently
had an odd need to see, in table format, contents of the ScheduleList-Archive
file (this is where your DispatchMap looks when displaying appointments for past
days). Until now, this vestigial form only allowed the ability to
search within that old data. For our own needs, we added a full-export
function. It's now available from within that form, should any have any
need to use it.
New "Route Performance Summary":
We've had a few people who wanted a separate export, for use outside of ServiceDesk, where they could quickly review what happened, for each tech, in regard to each of the jobs assigned to him on a prior day. That export is now available. To reach it, simply go to your DispatchMap (F5), and "PageUp" to the past day of interest (typically, it's likely to be just yesterday). With the day-of-interest displayed, hit Alt-P on your keyboard. That will expose a PrintOptions dialog box, now altered as follows:
The circled item is the new option. Just pick it, and follow the dialog to create your new export. You'll see the resulting file has fields for applicable Date, InvoiceNumber, Customer Name, Tech, Start Time, End Time, Money Collected, Whether the job was completed, and the Descriptive narrative as pertaining to his PostVisitReport.
Email Method Now Direct-Offered for Particular-UIS-Item Product History:
Long ago we added a method in the UIS form (Shift-F12) where you can easily printout a complete history of service involving a particular machine -- even if the machine happened to have been serviced for a succession of different owners and/or at a succession of different addresses. It's a very nice looking (and informative) printout. To get to it, just find and display the particular UnitInfoSheet that's applicable to the machine in question then click on its 'Show All Linked Jobs' button [1]. This displays a little listing of Invoice Numbers referencing each applicable job [2]. You've always been able to click on any such reference to see the job, or to click on the 'Print Summary' button at bottom of the list [3] to create the above-described printout.
Now, when you do the above and the Printer Selection dialog box comes up, it has a new section that can be checked -- for the sake of directing the output to email instead of (or in addition to) a printer.
Make your choice just the same as you do in any other
ServiceDesk context that offers this kind of option.
Other-Than-Mfr-Claims-Filing Fixed for KPI/ServicePower:
General Electric has long had a "contract service" program via which they dispatch for service repairs on non-GE products. Many ServiceDesk users are involved in such work, but we only recently became aware there is a problem when auto-filing claims for that situation. The FinishedForms auto-claim-formatting system was designed to list, as "manufacturer," whatever is applicable to the brand of machine being worked on. For OEM warranty work, that strategy is perfectly successful. However, when in a situation like that involving GE contract service (and assuming the underlying machine is not a GE product), it fails. This is because KPI/ServicePower uses the "manufacturer" field to determine which of their clients is ultimately paying.
So (and in short), under our longstanding strategy, if you worked on, say, an LG product under a GE service contract, KPI/ServicePower would end up interpreting your claim as being one for reimbursement from LG. Since LG is not a KPI/ServicePower client, you can't imagine (or perhaps you can) just how fast this resulted in rejection of your claim.
To fix the above, ServiceDesk will now look at the CustomerName (i.e., top box in the underlying JobRecord) to see if it is rendered as "GE," or if it contains the strings "G.E." or "GENERAL ELECTRIC." If it finds any of the above, it will configure your claim to list General Electric as the "manufacturer," even if the underlying "brand" is LG, Whirlpool, Maytag, or whatever (and don't worry, for there is a separate "brand" field in which the actual brand will still be listed).
As it happens, a very similar situation exists with respect to ServiceNet. This is another KPI/ServicePower client, and as we understand it is the entity that took over Maytag service contracts after Whirlpool bought the remainder of that institution. Just as with the GE contract service situation, for a successful claim, ServiceNet must be listed (in the underlying claim string that ServiceDesk assembles) as the "manufacturer," in spite of the product's actual brand. To accomplish this, please be certain that the underlying CustomerName (in any applicable JobRecord) is -- simply -- "SERVICENET."
Added a 'MAKE' Field to Parts Usage Rates Report:
By special request, the Parts Usage Rates Report
(menu option from Ctrl-F8 form) has a new field: Make. You can also sort
on this new field.
Sell-For Pricing No Longer Required in PartsProcess:
For several years, we've gotten phone calls with people wondering why PartsProcess items (F8 form) -- where they've ordered the part, checked it in, and used it -- do not get moved to the archive. Over and over, the answer has been because they were failing to put in the 'Sell-For' price, and the system was waiting for this little duty to be performed. With this release, you can now choose whether the system waits, or not. In fact, from this point forward the system will default to not wait. In other words, the new, unless-you-change-it-otherwise protocol is that the system will not require sell-for pricing, and will go ahead and archive when everything else is done, even if that element is not.
If you have any desire to change this new default, it's easy. Just bring up the PartsProcess form's "CheatSheet" (right-click anywhere in the colorful label area on top), and click on the new provided menu option:
In response, the system will present a dialog where
you're permitted to choose whether 'Sell-For' pricing is required, or not.
Moderate New Convenience in Archived JobRecord's History Section:
Someone pointed that, if you're looking at an archived-JobRecord that includes several (or a single large) AttnNote, such notes will typically cover significant portions of the narrative history, making the latter difficult to read (until and unless such notes are slid out of the way, which may leave them in a position different than where you ultimately want them, unless they are slid back). Now, to bring the historical narrative to the front, simply click down on it with your mouse, and hold. It will remain at the front (i.e., AttnNotes hidden behind) until you release your mouse button.
'Notes' Box in MasterPartsPlan's Supplemental-Info box Now Hyperlink Enabled:
The title says it all -- at least in regard to this
enhancement. I'll take this occasion, though, to remind that for any
textbox that you wish to have hyperlink-enabled, it's pretty simple underlying
programming to for me to make it happen. Just ask.
New "CheckOff Status" for Appointments in DispatchMap:
The DispatchMap has long used a series of symbols, displayed next to each appointment's reference, to indicate the status the appointment is in (i.e., whether confirmation has been requested from the customer, whether confirmation has been received, whether dispatched to the tech, whether the tech has arrived, finished, and/or completed his PVR, etc.). If you did not know, from your DispatchMap you can display a Map Legend (or Key) to show and explain each of these symbols. From the DispatchMap, simply strike 'K' on your keyboard (for Map Legend/Key), and you'll see the following:
At least, that's what you would have seen prior to this release. If you try it with this update (or later), however, your Key to Symbols will look like this:
As you can see, there's a new symbol. It's a red diamond, and is used to indicate the technician encountered a customer-NoShow when arriving for the job. The thinking is, if your dispatch manager is appropriately keeping tabs on the progression of jobs throughout each day (via the DispatchMap), the red diamond will allow her to easily see when and where a tech has been "stood up," and realize in such instances the tech may very likely have capacity for added jobs.
Please note the above symbols are specifically what's used next to each appointment's list-based reference in the DispatchMap. In addition to such variations in the listings, there are also variations in how the small-rectangular geographic references are displayed -- depending on CheckOff status (e.g., when a tech is at a jobsite its geographic reference shows with a yellow background; if he's completed the visit but has not done a PVR it shows with a large X through it., etc.). To designate this new "NoShow" status, the geographic reference will display with a single slash through it (as seen toward the top-right corner of the following ill