CRM solutions

Considerations when implementing a CRM Solution in Higher Education: Different Views for Different Users

It is imperative that when CRM solutions are implemented to help Higher Education providers manage their relationship with prospective students that they ensure that each team finds the system easy and intuitive to work with.  Part of ensuring this is to make sure that each user only has functionality and information that is pertinent to their job role.

Things the University should adopt a best practise approach including:

  • Consider your business requirements AND the individual users
  • Minimise clicks and complications for each team view
  • Ensure the solution is process driven, rather than technologically
  • Account for access restrictions
  • Aim for business, team and user satisfaction

Business teams

During the delivery of a software solution, the primary goal is to meet the business and operational directives of the University. There will be requirements relating to team and department functionality, but the visual presentation and views different sections of users work with is often overlooked.

A new software can often be a challenge to introduce to a business, and each team will have its own issues and questions. Presenting as many specific views, designed and optimised for team use will make that transition smoother. Attaining a level of buy in from users to the solution will have a positive effect.

 

Day to Day use

Everybody loves an all singing software, packed with functionality and exciting tools. On a regular day though, a user mainly needs to log in and do their job in a timely manner.

Taking into account the processes different users interact with more frequently, it is advisable to plan the presentation of the solution to meet those needs first. There may be a real business use for a brand new and exciting offering in the future, but it is not the main business use for many users. Therefore it does not need pride of place, or immediate showcasing, have it on a side or second menu. The main focus of the screen should be the day to day operations users require, and can access quickly and in an ordered manner.

Taking that concept into account, the priority of screens and functions available can be dictated and re-ordered by team and departmental responsibility

 

Restricted access

There may be the requirement to hide certain functions or data from some users. This may be due to a policy, or may be a decision made to enhance and improve the use of the system.

If a user shouldn’t or doesn’t need to see some functionality or data, the team view should reflect that. Accessing and using software should be intuitive and related to the user’s role. Unless there is a need to see other data and functionality, it should not be immediately displayed or possibly hidden.

Restriction may be useful for day access to new users, or a particular function required by some on a particular date, for example booking users into a meeting or a receptionist viewing staff and room availability. For these types of minimal use, smaller functionality availability can be enabled with just those requirements on display.

 

Teams, Managers and Individuals

Each team or business department within the University is naturally grouped together and a team view can be created. It is often important to consider the manager of the team who probably would require the same view as a base, but undoubtedly performs different tasks and checks. This can be achieved as a separate layer on the main team view.

Using this type of filter or “role” within a view, creates additional functionality and processes that only those assigned can see.  Using multiple iterations of this concept allows different sub teams and individuals to be segregated when needed and allows software to be tailored specifically for optimum use.