Flowchart of a typical job sequence

Based on the above, we want to give you a simple list explaining a typical job sequence, from beginning to end. For simplicity, we’ll do this with short sentences, and not much elaboration. We’ll be describing a typical scenario. Actual details will vary, depending on circumstances:

  1. ‍You initiate a job by typing its information into a Callsheet.
  2. ‍While the customer is still on the phone and you’re still in the Callsheet, you schedule the appointment via On-Map scheduling (right-click on customer’s address line).
  3. ‍With all the needed info typed into a Callsheet, you click on it’s Job/Sale button to create a JobRecord (F7). At first this record contains only information that was pulled from the Callsheet, but it’s still its own independent record, and is the document from which the job will now be managed. The Callsheet has done its job and is no longer needed. At the same time you created the JobRecord, ServiceDesk also entered the appointment into the ScheduleList (F6), making it viewable in the DispatchMap (F5), and so on. Also in the same process, ServiceDesk will print the service ticket (i.e., invoice) for the tech to take on the job.
  4. ‍When the scheduled day arrives, you’ll give the printed ticket to the assigned technician. In the DispatchMap (F5), you’ll check-off the fact he received it.
  5. ‍When the tech returns with the ticket, he should have handwritten a description of the work he did, parts he needs to order, parts he used from stock, items of money collected, and so on. You’ll now do a PostVisitReport in ServiceDesk (Alt-F7 or Alt/Ctrl-F7), reporting on each of these details.
  6. ‍Assuming parts needed ordering, those particular details from the PostVisitReport are fed by ServiceDesk into your PartsProcess screen (F8), which you then use to manage the parts inquiry and ordering process. When the part arrives, you also check it in via this means. Once all needed parts have arrived, the job’s status switches automatically into ‘Working to Schedule.’
  7. ‍Based on the above (and while reviewing those JobRecords that are in ‘Working to Schedule’ status, for which purpose you may use the JobsPerusal form, Shift-F7), you call the customer seeking to get them scheduled for completion (perhaps using the auto-dialer for the purpose of dialing). If at first you don’t succeed in connecting with a live human, you document your efforts via added notes in the JobRecord’s history section. When you finally do connect, you’ll again use the On-Map-Scheduling feature to figure a mutually convenient time, with the difference that here it’s initiated form the JobRecord, while earlier it was initiated from the Callsheet which originated the job.
  8. ‍When the scheduled day again arrives, you again give the printed ticket to the technician. Again, within the DispatchMap you check-off the fact that he received it. He pulls the parts that were ordered, and does the job.
  9. ‍Again the technician returns with the ticket, and again you do a PostVisitReport, this time inputting information regarding what was done on this second visit.
  10. ‍Assuming no more visits are required, it’s time to closeout the job by entering it’s completion into the SalesJournal (via the SalesEnter form, F9). In other words, you’ll now be recording the amounts that were involved in the completed sale. This essentially “puts the job to bed,” and of course is essential to your bookkeeping. If it’s a billed job, the system will simultaneously create an AccountsReceivable record (F3), from which you’ll then manage that concern. If warranty claims are involved, now is the time to do that as well, using the FinishedForms (Alt-F4) system.

That’s the typical sequence, in a nutshell. There are many more potential details, a plethora of systems designed to augment the above, add flexibility and security, etc., but those at least are the highlights of how a job typically progresses from beginning to end.