ServiceDesk 4.7.2 Update 10/11/12

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);