Halo

The Vision

Halo is one single platform for the collegiate University that enriches, simplifies and personalises people’s interactions with Oxford.

The unified customer relationship management platform (CRM) - now live - supports the entire student/alumni lifecycle. It will help strengthen connections and personalise relationships across the University, enabling collaboration, simplifying ways of working, eliminating silos and removing digital barriers.

This platform will be used not only by central functions but also within departments and colleges, creating a true Single Version of the Truth and a 360-degree view of our communities - students, visitors, alumni, research collaborations and elements of the professional staff lifecycle.

Core Benefits

Fit-Gap Design Approach

As we design and implement the new Halo CRM, we often refer to a “fit” and “gap” model to describe how the system meets Oxford’s needs. 

The “fit” (around 80%) is the part of the system that already meets our requirements. This comes from the partner-provided fundraising and engagement accelerator within Microsoft Dynamics 365, which is designed based on established industry best practice. In these areas, the system can be used largely as it is, with minimal or no changes. 

The “gap” (around 20%) represents where the standard solution does not fully meet Oxford’s specific requirements. These gaps are addressed through additional design and development to ensure Halo supports the way the University operates. 

This distinction helps us focus effort where it adds most value. Rather than changing the system unnecessarily, we prioritise using the existing functionality wherever it fits, and aim to only develop new features where there is a clear need. This will help us avoid the problem of over-customisation which has greatly slowed the performance and impacted the usability of the University’s DARS system. 

To sum it up; “fit” is what we can adopt, and “gap” is what we need to build. 

Filling the gap: Global build vs Local build

With the remaining 20% ‘gap, we are ensuring that development is tailored to how the University operates and its unique character as a diverse and decentralised world-leading University. The build for the ‘gap’ is divided into two parts: global and local. 

The global build includes the core customisations that support fundraising and engagement across the University. These are shared features and processes that will be used consistently by all areas, forming the common foundation of how we manage fundraising and engagement activity in the CRM. 

The local build covers smaller, more specific requirements which only apply in certain parts of the University but are important in those areas. These are designed to support unique operational needs—such as college-specific activities—without affecting the shared, University-wide approach. 

In this way, the global build ensures the ability to meet core fundraising and engagement needs, while the local build allows users to perform vital, extra functions relevant for their specific areas.

Halo products and continuous improvement

Our first products

HR Case Management, the first Halo product to go-live on the Halo platform launched in July 2025. The Halo platform now enables HR cases to be managed more consistently and securely, with full visibility from initial contact to resolution. By integrating PeopleXD data into CRM, we can streamline our processes, reduce duplication, and ensure a more responsive and joined-up service.

Our second product, Oxford Events is also now live and replaces a legacy system, OxTalks. The new product provides a solution for creating and curating event listings for promotion on websites and intranets across the University.

Continuous improvement

WORKING WITH A CONTINUOUS IMPROVEMENT TEAM (Author: Jamie Taylor)

What is a CI team?

A CI team or Continuous Improvement team (also known as a squad) is a group of individuals who have the necessary skills to:

• Collect feedback
• Prioritise ideas and add detail to them
• Build, test, and refine features
• Release changes incrementally
• Communicate progress and outcomes to stakeholders

They are charged with improving a product (software or a physical) by working closely with stakeholders and users to understand their needs and continuously enhance the product over time.

Definition of Stakeholders and Users

Before continuing, it is important to outline the differences between stakeholders and users:

• Stakeholders – individuals or groups who have an interest in, are affected by, or influence the product and its direction
• Users – a subset of stakeholders who directly use the product as part of their day‑to‑day work

We work with stakeholders to understand the overall direction and outcomes the product needs to support, while working more closely with users to design and build solutions that meet their day‑to‑day needs.

Using Stakeholder Groups

Stakeholder groups are valuable because they allow us to focus conversations and feedback on specific areas of the product, we are most interested in. Stakeholder groups should be identified following user research or other existing knowledge of the product. Creating and maintaining a group can be difficult, so nominating someone to take ownership of the group is often critical to building engagement and buy‑in

It is important that stakeholder groups clearly understand their role, what is expected of them, and which areas of the product they are focused on.

How feedback flows from idea to delivery

1. An idea is presented to us via various means: meeting with stakeholders, through user research sessions, UAT, stand-ups, system testing, etc.
2. The idea is fleshed out with the help of the person who came up with it
3. The idea is scored against basic criteria. We use population (how many people will benefit from this new idea), need (how much is this idea needed by those that will benefit from it), strategy (how much this idea aligns with our strategy), and effort (how complex this idea will be to implement).
4. We decide to build the idea and it is refined and broken down into smaller chunks of work
5. The work is planned into a future sprint

What we expect from users who work with our CI team

Participation in meetings, UAT, and other ceremonies is key. We work with stakeholders to ensure the product is aligned with what is needed, while building for users so they can
effectively complete the tasks the product is designed to support.

How often should CI teams meet with stakeholders?

How often CI teams meet with stakeholders depends on the type of stakeholder group.

For senior management, engagement is typically at most once a month. For the most engaged users (for example, a user group), meetings may take place fortnightly or at the
end of each sprint. Other stakeholder groups are engaged as needed, depending on the area of the product and the type of input required.

Maintaining regular relationships with stakeholders is important; without ongoing engagement, there is a risk that the team loses alignment and no longer builds the right
things for the people the product is intended to serve.