About Quiescing

This feature's purpose is to provide an added tool via which hands-on managers can more effectively minimize average Turn-Around-Times (TAT) -- defined as the quantity of days between job-order received and job completion.

For context, ServiceDesk's WipAlert feature is the "first-line-of-defense" in assuring your operation achieves small TATs. We believe every operation should make robust use of WipAlerts. If your operation is not doing so, we urge you to change.

Our Quiescing feature is designed to serve as a TAT-improving supplement.

Again for context (and, by way of defining contrast), the WipAlert feature is designed to allow passiveness, by a user, in terms of his or her own/active monitoring of jobs for appropriate progress. It allows this passivity by actively forcing matters to a user's attention, when it appears such matters have been neglected. If a user simply responds appropriately in each instance, the system all but assures rather good TATs.

However, it does not assure the best possible TATs.

Almost by definition, WipAlerts arise only after it appears there has been neglect (somewhat like "closing the barn door after the horse is gone"). They help enormously, but for those operations that are willing to manage with a higher degree of active/hands-on attention, better can be achieved.

More specifically, some managers want to actively and regularly review all pending jobs, with the purpose of using their own judgment, examining each to see if there is anything they can do to speed it along (paying particular attention, likely, to those jobs that are already taking the longest).

As it happens, the ServiceDesk JobsPerusal form (Shift-F7) is quite splendid for accommodating such manager review. He/she can narrow the category of jobs being reviewed, move instantly to the oldest (i.e., with already the longest TAT), and move record-by-record toward more current. Until addition of our Quiescing feature, however, this venue lacked an important component. As it happens, when a manager is engaged in this kind of review (in particular, looking at a specific job), she will often have to concede to herself something like the following:

"Yes, I'm going to have to wait five days for X to occur on this job, and there's nothing to help the fact."

Now, when that's the case in respect to a particular job, it's quite inefficient when the same manager, as she is the next day perusing through jobs for her "can I advance any" review, is forced to again eyeball the same job, again evaluate it, and again reach the same conclusion (plus repeat the next day, and the day after, etc.).

Avoidance of this waste is what quiescing is all about. Put simply, the manager can "quiesce" a job (such as that job imagined, for example, for a five-day period) where she knows she can do nothing to advance it.

The direct effect is, if in the filtering options she chooses the checkbox option that excludes quiesced jobs,

those that are currently quiesced will be excluded from the perusal-included items. Thus, it is only those she has not quiesced (or whose prior quiescent period has since expired) that will consume her visual and mental resources.

You may note there is a partial parallel here with the Hibernate feature as connected with ServiceDesk Callsheets. The most obvious difference is that Quiescing concerns JobRecords, not Callsheets. Another is that sleeping Callsheets remain visible in the universal Callsheet space, and are simply dimmed (i.e., non-illuminated) when sleeping -- whereas a quiescent JobRecord is only affected to the extent that, if a user chooses to show only "non-quiesced" jobs in the JobsPerusal form, those that are "quiescent" are simply not included in that form's perusal-list.

Aside from those obvious differences, there's another that, absent description here, you'd likely not realize. It is that, by design, a JobRecord's quiescent status is particular to a user. In other words, whatever I make quiescent for me, at my ServiceDesk station, has positively no effect on you, at your ServiceDesk station. This is to facilitate different managers pursuing their own particular monitoring strategies.

Of course, there is also the obvious distinction in nomenclature. We deliberately picked the terms "quiescing" (and its variants) for the "slumbering" system as connected to JobRecords so as to avoid confusion with its cousin in the Callsheets.

Please do not consider the quiescing feature a replacement or substitute for WipAlerts. Even if you're very actively employing this quiescing feature, WipAlerts should still be in play, if for nothing else as a last line of defense. Note too that, while WipAlerts are more of a junior-employee-level aid, the quiescing feature leans more on the side of being a management tool.