Enrolment process: one enrolment step, or multiple steps?

One enrolment step may seem simple but, depending on the amount of field it may also be daunting for the person filling out the information. To reduce the barrier to purchasing it might be sensible to have a brief form to gather necessary payment information, eg: Name, email, agreement to terms and payment method, and then follow up shortly afterwards with a request to complete the registration - prefilling with the existing data a form that gathers more information, eg government statistical information such as AVETMISS data and address details to send certificates to.

Tip: You do have the option to save ‘draft’ copies of forms which the student can come back to at a later date. This may assist with long forms that require detailed information.

Tip: If gathering details for private courses you may wish to send an invitation to enrol to a customer contact, adding a first step to the enrolment process before you gather student details.

Tip: Rather then creating forms at different levels that remove fields it is recommend that instead these fields are made ‘private’ or hidden. This avoids accidentally saving a form without those fields and losing the data. Saving a form without that data will remove that data from the record.

Tip: You may wish to have a student’s enrolment have multiple statuses, eg ‘enquired’ -> ‘draft registration’ -> ‘submitted registration’

Which data do you need to collect and when do you need to collect it?

The data to collect from a student depends on a number of factors:

• If the RTO is registered for reduced (single UoC) reporting
• If you are registered to gather funding on behalf of a student
• If you have (or the student has) an exemption from submitting Unique Student Identifier (USI) data
• If you have data required to be gathered immediately to, for example, qualify a student as having the necessary prerequisites, then this information will need to be gathered first, where as government data, required prior to sending completion certificates may be able to wait until after the course has started.

What information needs to be copied to the Contact record?

Broadly speaking information that is related to the student and would be expected to be maintained across multiple registrations is appropriate to exist on the contact record, eg ‘Phone number’ is likely to be student related where as the reason for doing this course is enrolment-specific. Funding data is likely to be enrolment specific whereas school history is student specific.

There are 3 main ways to take an enrolment:

• Public website enrolments: Via your website from a student visiting then choosing a course date.

• Manual administrator portal enrolments Manually entered by a course administrator via the administration portal (perhaps when a student phones or fills in a paper-based enrolment form).

• Private course enrolments Private courses, where a customer contact is asked to invite students who then use a special enrolment link to a private course.

There are variations to the above, for example a course administrator, having gleaned leads from a third party or responses at a trade show, might create an enquiry on a specific course that sends an email requesting the student to complete the registration, or links might be incorporated into a social media message so that when clicked on take the student directly to an enrolment form.

Public website enrolments

You may be using the iframe integration, linking from your website to the public pages that CourseSales.com provides or using a connector plugin (ie for Wordpress or Drupal). In any case your website gathers interested people to make a registration - the student selects a course category, location and date. Read more about website integration

The course administrator sees all enrolments appear in the list of documents, which is a running record of the documents as they arrive.

Depending on how your enrolment workflow is configured the first form may gather limited or detailed information. There may be many fields that are initially hidden or unavailable, when using for example the two-step registration process the common arrangement is to gather information that is necessary for the purchase, before AVETMISS and other data.

Below is an example of a brief registration form for taking an initial enrolment. It is designed to enable the student to quickly complete the enrolment. The enrolment workflow may include one or more tests ie subject related or a Language Literacy and Numeracy. These results will be linked to the enrolment, the student’s contact record is also created automatically. Upon submission the student will then be sent an email requesting them to complete the next step in the enrolment (see the next form screenshot).

This next enrolment form is the second step, notice the following regarding this form:

• it includes fields that were not shown in the previous form (but were in fact on the form: these fields were marked as private).

• it does not include the payment method field - as the payment completed in the initial enrolment payment details are no longer required.

• there is no ‘robot check’ as this form is sent to the student, it is not available publicly (where robots get their links)

• previously completed fields are pre-filled in for customers

• We have included the terms for agreement, but we could leave these out as they were already agreed to - it is worth while to include them just in case.

Manual administrator portal enrolments

The form that the administrator fills out includes information that is usually marked as private. This is actually the same brief form shown further above, but from an administration portal perspective. Notice these things about the form:

• Hidden fields are available to the course administrator that are not available to the student

• The payment method, while viewable on the form does not trigger a payment process within the administration portal.

• Some fields may be mandatory for the student to fill out on the public site but are not mandatory for the course administrator in the administration portal, eg password or agreements to terms.

Private course enrolments

The workflow for this type of enrolment workflow involves adding a customer contact - someone who is responsible for the course and knows who will be attending the training. This person is added as a login within CourseSales.com, while this person does not need access to the administrator portal they could be given access to the trainer portal to see the students who are registered, and see the schedule for the course. They are given the role ‘Customer contact’ (which does not need any permissions because they don’t need to log into the administrator portal.) This individual will be sent an email from the Course Date process path, requesting them to forward the email to students who may wish to sign up to the training.

Applying the necessary process step when editing a course date will send the email to the customer contact, see below.

Below is an example of the email to the customer contact.

The form for the students when they click on the link could either be the same as the brief form on the two-step process or a full form including AVETMISS information. Invoice information and payment information are not required if the course is being paid for by the organisation rather than by the individuals. Both these options can be available in the workflow. Note the following about this enrolment form:

• It is for a reduced reporting RTO that delivers First Aid training.

• it includes field validation for postcodes and localities (to reduce AVETMISS errors).

• there are no payment details collected, therefore no price is in the information box at the top of the form - this is a CSS customisation.

• there is no ‘save as draft’ button offered at the bottom of the form - this is a CSS customisation.

Requesting payment

If you need to take enrolments and also request that the student make a payment you can use a ‘Request payment’ step - this sends the student a link to complete the registration form which includes the payment workflow in addition to completing any additional data on the form that is required.

Waiting lists

Enrolments for courses that were once scheduled but there is either a location or date that is currently not scheduled can still be gathered, this involves setting up a course category, course master and course date that is a ‘waiting list’ course for those who have a preference but do not have a specific course to be booked on, they are effectively on a ‘waiting list’, and when their preferred course is available they will be transferred to it.