Target response dates

• Questions have a Target response date (date by which a response should be provided) set on entry to the system, according to parameters, and reset if a question is reopened.
• A parameter (2.12), and the Processing options defined for the form in use, determine how Response dates will be calculated for each question. 
  If Last useful date is selected at parameter 2.12 then Target date can be changed by changing Last useful date in the Change screen.
  If Objective response date is selected at parameter 2.12 then Target date can be changed by changing Objective response date in the Change screen.
• “The Needs attention – response” parameter in each Request form can be used to have reminders sent as questions that use that form approach their Target date.
• Staff always see response dates in that staff member’s own time zone and in the format determined by the Locale setting in their My preferences.
• Target response dates, if they are shown to clients, are always stated to clients in the client’s time zone and in the format determined by the preferred language set in their web browser (stored in RefTracker as their “Locale”).

A Target response date is attached to each question as it comes into the system, or is reopened. System administrators need to set their systems up so that the Target response date accurately reflects how their library operates. This is general information about what influences Target response dates so that you can set your Parameters, Locations and Request form processing options appropriately when you get to the point of making these settings.

According to the setting of parameter 2.12, the Target date will be set to the system calculated Target response date, the Last useful date specified when the question was entered, or the Earlier of these two.

The Objective Response Date is an indication of the date and time by when a response should have been sent by the library. It is calculated based on Objective response time information provided in the Request form used to enter the question, and the opening hours of the Staff Location into which the question is receipted (Receipt location). The objective response time set in the Request form is added to the time at which the question was received, rounded back to the previous parameter 2.11 controlled minute interval, and that becomes the Target response time if it is within the working hours of the receipt location, otherwise the Target response time becomes the next time the Location is open.

For example a question arriving at 4:12pm will have its Target response date set to 10:00am the next morning if the Request form’s Objective response time is 2 hours, and your library is closed from 5pm to 9am and Parameter 2.11. is set to 30 minutes (ensuring that Target dates are on ever set on the hour or half hour).

Libraries with service level objectives to fulfill can set the Objective response times in their Request forms to meet those service level objectives and should set parameter 2.12 appropriately to either Objective response date, or the Earlier of target date and Last useful date.

When a question is reopened, and its Target date is being set according to it Objective Response Date, the Target date is reset as if the question has newly arrived – in other words, when a question is reopened, the Target date will be reset to be the Objective response period form the date and time of reopen.

The Last Useful Date can be collected in Request forms. When the Request form is displayed the system takes its best guess at what the Target response date for this question will be and displays that as the default value for Last useful date with the Time component rounded up to the next available time value (this means that, if you display the form at 10:17am and the next value showing in the time drop down list is 10:30am, the time value will default to 10:30am). It calculates its best guess of the Last useful date by using the Objective response time of the Request form, and the working hours of the Service location for the location of the client seeing the form, or the working hours of the Location of the staff member displaying the form. Note that the final Target response date for this question may be different to this “best guess” in that the final Target response date will use the working hours of the Staff Location into which the question is actually received, where this Last useful date “best guess” is using the Service location of the client or the location of the staff member entering the details of the question. When completing the form, the client or staff member can change the Last useful date to a more appropriate date if necessary, and if overwritten in this way, the overwritten value is stored on entry of the Request form.  If the default Last useful date is not changed by the form user, no value is recorded for Last useful date if the field is set to optional, but if it is set to Mandatory, the unchanged value is recorded as it is the Last useful date accepted by the end user.
Libraries that negotiate response times with their clients should enter the negotiated response date in the Last useful date field and set their parameter 2.12 to Last useful date.

When a question is reopened, the Objective response date is recalculated if Target date is being set by the Objective response date.  If the question’s Target date is being set according to a Last useful date and the Last Useful Date has not yet expired, the Target date will not change.  This means that the client’s wishes are still being adhered to. If the Last useful date has expired and the question has been reopened, RefTracker presumes that the Last Useful date is no longer an issue, and recalculates the Target date ignoring the expired Last Useful date.  If the reopen request indicates that a later Last useful date is acceptable to the client, you can (and should) change the Last useful date using the Change screen.

To ensure responses are provided on time, Target dates are colour highlighted in all Search screens e.g. My questions and Open questions, and batch processes can be used to escalate unattended questions approaching their Target date, to a Supervisor. The “Needs attention parameters in each Request form determine when the colour highlighting applied to Search screens changes.

RefTracker takes time zones into account if you have branches in more than one time zone. The Target response date quoted to the client is quoted in relation to the client’s time zone, and any staff member looking at the question will see it in their own time zone. For example a question submitted by a client in Sydney (UTC+10) might have its Target response date set for 9am on 5th May Sydney time. If the server is located in Auckland (UTC+8) the Target response date will be saved to the database as 7am 5th May (i.e. in server time), but a staff member in London (UTC+0) will see the Target response date as 11pm 4th May. The time zone calculation takes daylight saving into account.

How to change the format of the dates you are seeing

If you are seeing dates in RefTracker in the wrong format, for example in mm/dd/yyyy when you prefer dd/mm/yyyy, you will need to change the Locale setting in your My preferences.  RefTracker will automatically display dates in the format determined by this Locale setting e.g English (United States) will display dates as mm/dd/yyyy.