1. Enquiry & Contact Management (CRM Phase 1) Contacts & Incidents 12 November 2014

2. Objectives 1.Update you and receive feedback on the Contacts & Incidents functionality being configured in the RightNow prototype (basic system) 2.Brief you on the decisions and next steps required for deployment within your Faculty 3.Confirm a way forward from here University of Adelaide2

3. Agenda  Reminder of the Project Purpose & Objectives  Share & Validate: - Outcomes from Contact & Incidents Discovery Workshop - Updated Process Maps  Things to think about: - Mailboxes & Web Forms - Queues - Contact records  Next Steps  Discussion: - Review progress to date, how we will measure success and what we should focus on moving forward University of Adelaide3

4. E&CM Project - Purpose & Objectives University of Adelaide4 Our Purpose: Deliver an enterprise solution for enquiry and contact management and a foundation for an integrated CRM platform for the University. Our Objective: Improve our clients’ overall experience by understanding, connecting and serving them better by:  Coordinating our relationship from a “whole of University” basis  Providing a single view of clients over time and all channels of communication  Customising communication to the needs, preferences and interests of our clients  Reducing the effort required by our administrative/service processes  Using “actionable” information to make the most of our resources

5. Contacts & Incidents Discovery Workshop Can this work for you? Share & Validate University of Adelaide5

6. Terminology  Contact is an individual with a contact record Organisation - Any company, business unit of a large company, or government agency that has an organisation contact record  Incident - Any question or request for help submitted by a customer  Incident queue—A view of a list of unassigned and open incidents Service level agreements - A service contract or level of service that applies to a contact or organisation (i.e. turn around time for enquiries) Opportunities - Information about a specific sale or a pending deal that is tracked and maintained (e.g. lead for future students) Mailing - A collection of one or more messages sent to one or more contacts Opt-in—The explicit granting of permission by a contact to receive email communications from the University. They can be specific to certain mailing lists or applied globally across all mailing lists. University of Adelaide6

7. Contact Records - Individual  They are fundamental to realising our CRM objectives  Created when: - a customer creates an account on the customer portal - a customer submits a question on the ASK A QUESTION page - a staff member creates them using the contact workspace  We will endeavour to get name, email address and phone number as minimum contact details  Student and Staff ID is a unique identifier (otherwise use email address)  Contacts can be linked to organisations, service level agreements, incidents, opportunities and marketing mailings (opt-in status)  Each contact may be associated with only one organisation University of Adelaide7

8. Contacts CONTACT TYPE Significant relationships with the UoA will be classified Yes/No list Can have multiple contact types for one individual ATTRIBUTES These are characteristics associated with a contact type Reflect the status of that person in the relationship (mutually exclusive) Choose only one option for each attribute from a drop down list Can be used for segmentation purposes E.G. CONTACT TYPES: Current Students YES/NO Future StudentsYES/NO AlumniYES/NO ParentsYES/NO International AgentsYES/NO Preferred PartnersYES/NO SchoolsYES/NO ResearchersYES/NO UoA StaffYES/NO Industry YES/NO Community YES/NO GovernmentYES/NO E.G. ATTRIBUTES FOR CURRENT STUDENT (CHOOSE ONE FROM EACH DROP DOWN LIST) International OR Domestic OR ATSI Undergraduate OR PGCW OR HDR Award OR Non-award OR Short Course University of Adelaide8 Note: Additional fields can be added (called “custom fields”) that are required by the UoA (e.g. flag Ausaid, UAP). Clear need and commitment to maintain required.

9. Screen Shot: Example of Contact Record University of Adelaide9 Note: This is incomplete, illustrative only

10. Incidents Incidents are created as a record of the customers interaction: – Automatically when customers request help through email or the Ask a Question page – Manually by staff who are contacted by phone, mail or face to face Incidents can have multiple communications associated with it When opened, an incident contains the subject, customer’s question and contact information Incidents are assigned to queues The order in which you work on incidents is determined by the queue priority and any other business rules University of Adelaide10

11. Incident Queues – Managing Incidents In general, no auto-routing to queues will occur except for specific web forms and mailboxes Triage by Ask Adelaide (default queue) Staff are allocated to groups who are responsible for incidents within a queue Incidents will be automatically assigned to staff within a group/queue (push vs pull) Within a queue, incidents will be handled on a first-in, first-out basis Staff can manually assign incidents to individuals within their group or to other queues (i.e. not to individuals within other queues) Queues can be managed by Supervisors (if required by operational needs) Note: When responding to incidents you can configure the outgoing mailbox address (e.g. signature) University of Adelaide11

12. “Click, Click, Done” - Sign Post Incidents Available to provide statistics on incidents that may be high volume and low value In addition to full incident records there will be two “light weight” options: Option 1 - Anonymous Pick type of person (default to domestic student) & question type e.g. Ask Adelaide Option 2 – Contact Identified Search for existing contact record and question type University of Adelaide12

13. Sign Post: Opening Screen University of Adelaide13

14. Sign Post: Future Student, General Enquiry University of Adelaide14

15. Sign Post: Future Student, Search for Record University of Adelaide15

16. Sign Post: Student Known, Incident Created University of Adelaide16

17. Status – Manual or Automated University of Adelaide17 ANSWERED Waiting on Client Updated by Client Expert Advice Received Referred for Advice Referred to Expert OPEN/ REOPENED Advice Received FIRST QUEUE Ask Adelaide is default CLOSED Automatic – 7 days since contact with Customer More information is requested from customer Forward to SME (no access to RightNow ) Incident assigned to another queue Incident is answered directly Student/Customer raises an enquiry If via web form - receives automatic acknowledgement

18. Process Maps Share & Validate University of Adelaide18

19. Process Maps Review flow charts: Telephone Face-to-face Web University of Adelaide19

20. Mailboxes & Web Forms, Queues, Contact Records What’s your preference/Which model will work best? Things to think about University of Adelaide20

21. Mailboxes & Web-Forms Generic email addresses and web forms will be used to automatically assign incidents to your queues Example of Griffith web formExample of Griffith web form Example of USQ web formExample of USQ web form Web-forms can identify where an incident was generated from (i.e. website or customer portal) – Consider including web forms on your websites? i.e. Ask a question Generic email addresses are to be rationalised – Unworkable list of 954 generic email addresses identified You can decide where your generic email addresses go to (e.g. queue) University of Adelaide21 Generic Email Address What is it used for?Who receives these emails? What queue should it be allocated to? Determined later

22. Queues – Option 1 Ask Adelaide AA Queue 1AA Queue 2AA Queue 3 Refer to Faculty Triage Queue Faculty/School Queue 1 Faculty/School Queue 2 Faculty/School Queue 3 Refer to another queue Refer to SME University of Adelaide22 Ask Adelaide only refers to a single Faculty Queue Faculty Queue assigns incidents directly to Tier 2 Faculty and School Queues Ask Adelaide does not use the Refer to SME functionality for individuals within the Faculty Assumes Faculty is best placed to assign incidents Note: Change of colour indicates status change; Only showing Ask Adelaide and Faculty/School queues

23. Queues – Option 2 Ask Adelaide AA Queue 1AA Queue 2AA Queue 3 Faculty /School Queue 1 Refer to another Queue Refer to SME Faculty /School Queue 2 Refer to another Queue Refer to SME Faculty/School Queue 3 Refer to another Queue Refer to SME University of Adelaide23 Note: Change of colour indicates status change; Only showing Ask Adelaide and Faculty/School queues Ask Adelaide may refer directly to a Queue at Faculty or School level or to an individual SME

24. Queues – Option 3 Ask Adelaide AA Queue 1AA Queue 2AA Queue 3 Refer to Faculty Triage Queue Refer to another Queue Refer to SME Faculty/School Queue 4 Faculty/School Queue 5 Faculty /School Queue 2 Refer to another Queue Refer to SME Faculty/School Queue 3 Refer to another Queue Refer to SME University of Adelaide24 Note: Change of colour indicates status change; Only showing Ask Adelaide and Faculty/School queues Third option is only relevant if there are a hierarchy of queues (e.g. T1, T2, T3) that an incident must move through sequentially e.g. All incidents will go to the FoP Hub first and only be referred to Schools if it can’t be answered at that level

25. Contact Records  At “Go Live” contact records will include all current students and some Faculty of the Professions records  A principal objective of the Project is to create a single University contact record for improved relationship management (i.e. decommission independent contact lists in other locations)  What contact lists currently exist in your Faculties/Schools?  Need to identify, collate and review these lists  Use this information to identify custom fields and plan approach for the creation of additional contact records  Required records may require manual input over time  Clarify what we will hold against contact records in RightNow versus TRIM University of Adelaide25

26. Standard Reports Start with what is available out of the box What process is appropriate for ongoing development? e.g. PeopleSoft University of Adelaide26 Type of ReportExample Agent total incidents assigned/responded to av. time to respond/close time logged in to RightNow Customer Satisfaction 10 most satisfied/least satisfied contacts and organizations by agent, group, category Email no. and type of incidents submitted by email no. associated with particular mailbox Incident no. of incidents and no. of responses per incident time to assign/respond/resolve no. reassigned Queue Number and max. time incidents spend in each queue Service Level Time to respond to incidents and % within SLA

27. Business Processes, System Configuration & Deployment Plan Next Steps University of Adelaide27

28. Next Steps for Faculty University of Adelaide28 ActivityWhen Identify attendees for the prototype demonstration21 st Nov Attend demonstration of prototype for KB/C&I (Faculty Specific); Finalise “things to think about” to configure RN for contact and incidents December (TBC) Scope training needs/profile settingTo be agreed Identify current generic email addresses and potential to decommission To be agreed Identify webpages to include “Ask a question” web formTo be agreed Review documented business processes: “Managing Contacts”, “Managing Incidents” December/January Identify and collate existing contact records to be included in the RightNow database To be agreed Participate in User Acceptance Testing of C&IApril – TBC subject to deployment plan

29. Review progress to date, how we’ll measure success and our focus moving forward Discussion University of Adelaide29