What to consider when designing your Request forms

Now that you know what Request forms you need, let’s look at what should be included in each form.

  1. Look at the data that needs to be collected in each form and assign a RefTracker field to be used to collect each piece of data. There are standard fields and code tables in RefTracker to cover the more usual reference and bibliographic requests, but there are also “user defined” fields that you can apply to any use. See the next section for more information about the data entry fields available in RefTracker. RefTracker fields must be used consistently within your organisation, but can be adapted to your specific needs. You can even change their names to reflect the adoption to which you have applied them. For example, if you are going to use the Age/group field to record the client’s faculty, then you can rename it to “Faculty” and set appropriate values for its drop down box in Code tables. Similarly you can rename data entry fields like “Client reference number” to “Matter number” for example, by using the Data dictionary.
  2. Decide whether each form will be available for use throughout your system, be linked to a specific location, and what levels of staff should be able to use the form. There are Request form options that can be set to control all of these aspects of the operation of your form.
  3. Decide how questions coming in through this form should be processed on arrival – for example, sent to the pool, allocated to a specific staff member, closed on arrival (more about this in the Edit options section later). These aspects of your form’s operation are set in its Request form options.
  4. Decide what emails need to be sent in relation to this type of request – for example, a confirmation email to the client on arrival of the question, a staff allocation email, a response email; and the layout required for each of these emails. What emails are sent, and the specific layout are selected using Request form options. How to create new email layouts is covered later in this manual.
  5. For each form, decide on your service level objective in relation to the time from arrival of the question to delivery of the response, and whether you want to display the resultant objective response date to the client. These aspects of your form’s operation are set in its Request form options.
  6. For each form decide the features that you need included when closing questions – Should the questions be automatically closed on arrival, do users need to decide whether the question should be included in the KB, should they enter an Expertise value, should Category values be entered? There are Request forms options covering all of these.

Keep this information in mind as you learn how to design Request forms, so that you can create the forms you have identified here, later in this training.