Overview

The Finished-Forms interface AltF4 was created to provide a place where you can view and edit every detail about a ticket on-screen, then print, email or electronically transmit. By “every detail,” we mean not just the same job-initiating information as is available with the up-front ticket, but also details that come only with job-completion, such as description of work done, listing of materials used, and itemization of charges. Hence the title: Finished-Forms.

While the Finished-Forms interface is today so elaborate as to deserve this entire descriptive section, it did not begin that way. Its first incarnation featured solely an on-screen/editable representation of the NARDA form. Prior to this, warranty servicers were hand-writing onto actual paper NARDAs, which were in turn postal-mailed to the manufacturer for submission of each warranty claim. This hand-filling-in process was laborious, so we were asked to create a mechanism whereby ServiceDesk would instead machine-print applicable text into the NARDA’s spaces.

To fulfill the request, we made an on-screen representation of the NARDA, with editable boxes in each place where text goes on the paper NARDA equivalent. We further made mechanisms whereby information, as applicable to any particular job as present within ServiceDesk could be made to auto-fill to such boxes. And, of course, we made mechanisms via which such text can output to a printer.

That, essentially, was the birth of our interface, and we did not immediately envision it as having broader application. Very quickly, though, it was realized that the very same on-screen-editing-and-then-printing capability would be handy for ticket formats other than the NARDA. Thus, we soon added two alternate-form interfaces.

The “Custom” form interface was designed generally to mirror the up-front ticket in format, but to of course (and in contrast) include full completion details, with on-screen editing, etc. (this is a form that, whether pre-printed or otherwise, requires a background image). The “Generic” form interface was designed to be, well, more generic in character, and with a design that requires no advance background (hence it is inherently suited for printing to previously blank paper).

With these alternate forms, it became easy to produce a completed ticket that was perfectly machine-done in its entirety. Thus (and as an example), if you needed to produce a very nice ticket for after-the-job mailing to a customer (no messy handwriting, no grease on the paper, etc.), it was now very simple to do so. Plus, we added an option to email the image, as opposed to printing first and then postal-mailing.

Before long we encountered our first clients involved in significant point-of-sale (POS) operations. Usually, it was a service company or dealer that also had a “parts counter,” conducting over-the-counter parts sales. They wanted to know how to manage this in ServiceDesk, and we realized our Finished-Forms interface was the best answer. By and by, we elaborated on its features to make them more amenable to effective POS functions, and eventually added a fourth form (the POS form) specifically designed for a streamlined POS sequence.

Finally, after launching our SD-Mobile system with its own unique, in-field ticket, we realized there was occasional need for the office to interface directly with (and in editable format) the ticket a tech created in the field. Hence, we added the Finished-Form’s Mobile ticket.

This is the history, briefly stated, of how the Finished-Forms interface arrived at its state today. We sometimes provide such a historical overview because, simply, it’s often easier to understand the current structure when it’s placed into an accurate developmental context.

With the above done, we’ll now discuss the two major areas of operation, within the Finished-Forms interface, that significantly need elaboration.