In the earliest ServiceDesk incarnations (pre-2000), there was no Finished-Forms interface. In regard to invoice/ticket options, ServiceDesk had but one. It was for what we now call our “up-front” ticket. Machinery for that option is distinguished by the fact that final text as printed can never include more than job-initiating information (the form itself can have spaces for many other information items, but ServiceDesk cannot sensibly populate them) In other words, the up-front ticket machinery can manage the names of parties to the job, applicable addresses and telephone numbers, description of machine to be serviced, symptom, etc. But it cannot manage a description of work performed, materials used, and what the charges are. Mechanisms as associated with the up-front ticket simply do not include such facility. They were not designed for it.
Nor was any such facility needed by the first ServiceDesk users. Those earliest clients did not do OEM warranty work (hence no need for filing warranty claims), and did not do point-of-sale (POS) operations (hence no need for a counter ticket that includes a listing of items sold, prices and total, etc.). The simple up-front ticket sufficed for all needs. Printed for the techs before they went out each day, all further details (concerning work performed, materials used and fees) were hand-written by the techs on location at each job. In a nutshell, all ServiceDesk tickets in that era ended up as hybrids: partly machine-created, and partly hand-written.
The above is explained to contrast with this chapter’s topic. The Finished-Forms interface (Alt-F4) 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 an entire descriptive chapter (this one), 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 ultra-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.
