The model provided here is a three-tiered approach, with a fourth section defining key attributes for services and service offerings (see figure 4). The intent is to foster understanding of the catalog contents by presenting them in a way that makes sense in the higher education environment, starting most broadly and moving to more detailed information as one traverses the structure.

• Service Category: A logical grouping of services that benefit from being managed together. These high-level groupings should be meaningful to the IT service provider to facilitate budgeting and governance of services. Some institutions might choose to make these groupings visible to end users, whereas some might not and might even have different groupings (see the discussion of "views" earlier in this document). These categories should reflect the strategic goals of the institution and align with the overall governance model. Governance of IT services, including deciding on major projects, developing strategy, and managing funding, is generally conducted by groups aligned with the service categories. Most service catalogs will consist of six to ten service categories. Examples of service categories might include communication and collaboration, infrastructure, and teaching and learning.
• Service: An end-to-end IT service that delivers value to customers, typically not identified by specific product or application names. The service combines people, processes, and technology to provide outputs or results that enable business capabilities or an end user's work activities and desired outcomes. Multiple related services are grouped in a service category. Examples of services appearing in the Infrastructure service category, for example, might include database management and network and connectivity management.
• Service Offering: The specific technology-focused activity or product used to deliver a service. These can be software bundles, custom application solutions, or other technology that enables a service offering. Multiple service offerings might exist for a single service. Examples of service offerings for an email and collaboration service might include Microsoft Exchange, Gmail, email distribution lists, and university and college event calendars.
• Service Attributes: Key information about individual services or service offerings. Different views of a catalog might contain different attributes focused on the catalog's audience. Some examples include service name, service description, audience, benefits, service charges, and requirements.

Services live in a single category; however, some services might be cross-referenced in other categories via the related services attribute.

Start building your service catalog by reviewing and using the model categories and taxonomy provided below. The model is expected to generally align to any institution’s service catalog needs. We recommend you start with this template and, working with the stakeholders at your institution, tailor it and adjust any categories or services to meet your local requirements.

In building your service catalog, it is essential that you involve and work with your constituents to discover what services they want, the language they would use to denote those services, and what requirements they have regarding the delivery of those services. This collaboration will help align expectations with service provisioning, improve communication, and result in a collection of services that bring value to your intended audiences. It will further aid in defining service-level agreements that address availability, reliability, and recoverability in a business continuity model. Using this constituent-led operational model, your level of success in providing services can be evaluated objectively. In addition, monitoring and reporting agreed-upon service metrics provides a basis for discussion between service provider and customer and enhances mutual satisfaction in the delivered services. Continuing to involve the customer in the ongoing development and maintenance of the service catalog helps ensure its success.

Some aspects you might want to consider when building your service catalog include the following:

• You might have different views of your catalog. Typically, you will have a single catalog but might have multiple views for different audiences. See the above section, Service Catalog Views and Audiences, for more on this.
• The model is not intended to be prescriptive. You might find that some services at your institution are better aligned in a way that differs from this model. For instance, your institution might prefer to situate "Polling and Surveys" (currently in the "Teaching and Learning" category) in the "Communication and Collaboration" category, or you might discover that it makes sense to shift "Media and A/V" systems (now under "Communication and Collaboration") to the "Teaching and Learning" category.
• The model groups services together by function and does not attempt to align them to user groupings. For instance, a personal computer user might consume services from the Communication and Collaboration, Desktop and Mobile Computing, and Infrastructure categories. A different view can be used to group these together for the user, if desired.
• It is a best practice to avoid structuring your catalog to match your IT organizational structure. The model does not align services by how or where they operate or how the IT organization supports them. For example, an IT organization might manage cloud-based collaborative storage and on-premises disc-based storage in different departments, but both services would appear in the catalog as service offerings under "Server and Storage Management."
• Some platforms might provide multiple services and be listed in multiple locations. For example, PeopleSoft, Workday, G Suite, Amazon Web Services, Azure, and others might be listed in more than one category or service area as appropriate.
• If a service has a consulting component, it should be included with the service it supports. Some common examples include educational technology consulting, user experience design, and data integration.
• IT services that are consumed only by central IT are not within the scope of this model. Services consumed by central IT as well as other audiences are included, however. If you want to include internal-only services, they might not align seamlessly to this model.

Listed below are suggested service categories that we believe cover the strategic areas for most institutions. With appropriate local modification, these categories should assist in facilitating activities such as budgeting and governance. Most institutions will have 6–10 service categories:

Services

Under each service category, we have listed common IT services (end-to-end IT services delivering outcomes to customers) offered in higher education. This list should be broadly representative but might not be comprehensive for all institutions. Your institution might not offer all of these or might have additional services. For each of these services, there might be a number of individual service offerings representing specific technology-focused activities or products that are used to deliver the service.

An analysis of the 2017 EDUCAUSE Core Data Survey found that, on average, 37 of the 52 services in this catalog are supported by an institution's central IT department.1  The analysis also showed that the specific services supported varies substantially—only a small number of services, mostly related to infrastructure, are centrally supported at more than 90% of universities.

Service Attributes

Service attributes help define and describe both services and service offerings. They provide information related to managing, providing, and accessing each service or service offering. One can think of attributes as a set of characteristics of each service or service offering.

The particular attributes that are presented to the person reading the service catalog might change depending on that person's role within the institution. For example, the "service cost" attribute, in contrast to the "service charges" attribute, might be hidden from faculty, staff, and students but visible to IT staff and governance members.

Depending on the maturity of the institution's service catalog and service management program, some attributes might be required and others just suggestions. For instance, the service owner role might be mandatory in institutions where the role has been formally established for all services, whereas it could be optional in institutions where the role has not been fully established.