There are many different ways in which a human operator might designate an appointment for a certain date and time. Being intelligent as we are, we probably could decipher the intent behind any format that makes reasonable sense in our own language. Unfortunately, computers and software are still not so smart as we when it comes to matters seemingly so simple. It is fortunate in this regard that, in respect to much of what you type into a Callsheet or other form, there is little need for ServiceDesk to understand what's there: for the most part, it simply records what you've entered and transmits or displays it, as appropriate.
In regard to what's entered in the 'Appointment Date and Time' box, however (and later transferred to a job’s appointment reference in the ScheduleList), ServiceDesk must be able to make a sensible correlation between what's entered and the actual calendar context of date and time. For this reason, it’s necessary to use a format that ServiceDesk, being relatively dumb in such matters, is prepared to interpret.
Specifically (but with some exceptions, to be discussed), ServiceDesk is programmed to expect three particular "words" within any appointment reference. It defines words as adjoining groups of characters, each separated by a single space (i.e., it would think "o8kl3 v9f drt" is three words).
For the first word, ServiceDesk expects to find either a single number referring to the desired day-of-the month (i.e., a number in Arabic text between 1 and 31) or an ‘X/X’ –type of number/number combination that refers to the month and day-of-month (as in “12/31” or “2/19”).
For the second word, it expects either a weekday name, or as many leading characters from such a name as you may choose to use (e.g., "MON").
Finally, for the third word, it expects any of the following:
No other forms of text (such as, for example, “1stCALL” are acceptable for this third-word position
Thus, a complete appointment entry could look like any of the following:
Notice that in some of these examples there are additional words after the first and magic three (we even have an example where “1stCall” is acceptable as a fourth word). ServiceDesk doesn't mind such additional words (which you can use internally as notes). It simply must see the magic first three words — each in one of the described-acceptable formats.
To make things easier for you, ServiceDesk does manage some minimal intelligence in regard to interpreting these entries. Notice, for example, that you are not expected to specify 'AM' or 'PM' in regard to the time (nor to use military time). ServiceDesk will assume that a 9-12 appointment must be for the morning, and that a 3-6 must be for the afternoon. It becomes more difficult for this distinction, obviously, as your appointments reach the more extreme edges of the day (is an appointment designated for "7:00" more likely to be am or pm, for example?), so ServiceDesk establishes a simple dividing line. If the number designating a single time, or the average between a pair of times (i.e., 10:30 when "9-12" is stated) is 6:59 or less, ServiceDesk assumes it must reference a 'PM' time. If it is 7:00 or greater, ServiceDesk assumes you're intending 'AM' time.
Additionally, when allowing you to state merely a single number for the day of the month, ServiceDesk must somehow deduce which month and year you're referring to. Essentially, it seeks and finds the last time when such a number arose in the calendar, as compared to the present date. If the found date-number was less than five days previous, it assumes that as the date referenced. Otherwise it assumes that your number refers to the next time the number arises in the calendar.
While it’s convenient to be able to state a single number for the date, you can readily see (based on the above) that if you’re wanting to specify a date that’s more than about 25 days hence (depending on number of days in the current month), it would be impossible, on the basis of a single number alone, for ServiceDesk to accurately interpret your intent (the described assumptions would fail). For that reason, and for those specific instances where you’re specifying an appointment further into the future than 25 days, you’ll find that both auto-insertion methods will create a more complete reference (e.g., “12/31 THU” rather than merely “31 THU”). In this instance, obviously, there is still the need for ServiceDesk to infer the year. Roughly, it uses the same convention as when inferring both month and year, but in this case will correctly decipher your intent so long as you’re not attempting to schedule more than about 51 weeks into the future (or again, more than five days in the past).
It may seem odd when first considered to find we’ve set it up so that you need put in only a single, day-of-the-month number for the date, rather than a more standard format such as “12/31/01 9-12”. The reason is because we also want a reference to the day-of-the-week (for verification of intent as described in the following paragraph, and related reasons), and yet we want to keep the appointment reference relatively short (a reference such as “12/31/01 MON 9-12” would obviously be unwieldy). Thus we find something like “31 MON 9-12” is generally most effective, particularly because the applicable month and year should in virtually all cases be obvious from context. Regardless, you’ll note that you can select an option in the Settings form that will cause the month indication to be included in all instances, if that is your preference.
As for as the second-word, day-of-the-week portion of your entry, ServiceDesk uses it solely for the purpose of verifying you have not, in some manner, goofed in regard to the intended day of the appointment (it checks on this during the Job Creation process). Thus, if you've specified "16 FRI 1-4", but the following Friday is, in fact, the 17th, ServiceDesk will alert you to the error and require correction—thus helping you avoid a very common mistake. Indeed, ServiceDesk checks the entire format during the Job/Sale process, and will coach you in making necessary corrections.
