Getting Started with Your TeamDynamix Service Catalog

Summary

This getting started article will help Administrators to build a Service Catalog using the TDClient and TDAdmin interfaces.

Body

This getting started article will help Administrators to build a Service Catalog using the TDClient and TDAdmin interfaces. The user must have the Administrator privileges in both interfaces.

In this article:

Overview

A service is a means of delivering value to customers. If users want the benefits and value of utilities such as email, storage, and wireless networking, but don’t want to assume the burden of managing those items themselves, an IT department provides those things to them as a service.

The TeamDynamix service catalog is a list of services that customers can choose from and request. This is a key support structure for ticketing applications. For example, tickets can be related to services, and every form can have a client portal view for use in the service catalog. The service catalog is also key for project requests as project request forms can be built out via the service catalog.

Service catalog entries can initiate a new ticket within any ticketing application, begin a new project request, or be a link to another website.

Each service and service offering includes a detail page for you to document and publish various pieces of information about the service. As you begin implementing your service catalog, you need to consider the various services provided by your department, organization, or institution. You can categorize and directly link to services for your users to easily find the services they wish to request.

If you are new to service catalogs, we highly recommend reading the EDUCAUSE Center for Analysis and Research (ECAR) article on Higher Education IT Service Catalogs

Transcript

The Service Catalog Module will discuss how to use both the TDAdmin and TDClient interfaces to create and organize your services to be requested by users. You will discuss how to use categories, services, and service offerings on your portal to set up a structure that is easy for your users to navigate. You will also learn how to use visibility permissions to show and hide services for different user bases.

Where to Find This

This feature appears in the TDClient and TDAdmin interfaces.

TDAdmin is where Administrators can go to manage services, categories, and forms; and TDClient is where both Administrators and service owners/managers can go to manage services, categories, and forms.

Navigate to your service catalog and settings following these paths:

  • TDAdmin
    • Applications > [Ticketing Application] > Request Forms
    • Applications > [Client Portal Applications] > Service Catalog > Services or Categories
    • Portfolio Planning > Request Forms
  • TDClient
    • Services

Where to Start

An Introduction to Service Catalogs [Video 35 min]

Define your services before you define your service categories. It's easier to define what a container should be called after you have items to put in the container and can see what you need.

Services can be defined outside of TeamDynamix before configuring them. You could do your planning in Excel by using the attached Defining Services Template.

Collaborate with other teams. It is easier to ask each team lead in your organization to think about their services than for one person to try to define all of them.

Talk to your tier 1/first line of support staff, as they will interact with the ticket more day-to-day than those in managerial roles.

Follow the ITIL Guiding Principle – Start where you are. If your organization has an existing catalog, take what works from it and leave what doesn't. There is no requirement to start from scratch.

If you are having trouble getting started, check out professionalservices.teamdynamix.com. Here you can find sample services that you can use for your own environment.

Creating Service Entries

TeamDynamix Services can be created from the TDAdmin site or directly from TDClient, assuming the proper user permissions. To learn about creating a service, see Creating a Service for Requests.

After establishing your services, you can move on to creating service categories.

Note: Forms built via TDClient are considered service-specific forms and can be edited later via TDClient. Forms built via TDAdmin are considered shared forms and can be used for many services, but they cannot be edited later via TDClient.

Note: when using multiple Service Catalogs with multiple Client Portal in TDNext forms all Services in all Service Catalogs will display in that service lookup. To help support staff find and select the correct service, append the service name with the service catalog name such as "[Name of Catalog] - [Name of Service]". For example: "TDX Academy - New Account Request."

Note: In some scenarios, you may need to create a Service Offering for your services that your organization provides. For more information on Service Offerings, please take a moment and read through Service Offerings for an overview of it and how to utilize it within TeamDynamix.

Creating a Link Service to Link to Another Site

To create a service that serves as a link to another site of your choosing:

  1. In your Services application in Client Portal, click the New Service button.
  2. Select the Category this service will primarily reside in.
  3. Add the Name, Short Description, Long Description, add ordering, select the Manager for the service, choose the Assets/CIs application the service will reside in, and add a Maintenance Window if needed.
  4. Select Link in the Request Application field. A new field will appear which allows you to enter in the URL of the site to which you'd like to link this service.
  5. Choose the text to appear on the Request Service button in the service catalog.
  6. Add Tags for the service to make it easier to search for it.
  7. Click the Save button.

Creating a Project Request Service

To create service that submits a project request:

  1. In your Services application in Client Portal, click the New Service button.
  2. Select the Category this service will primarily reside in.
  3. Add the Name, Short Description, Long Description, add ordering, select the Manager for the service, choose the Assets/CIs application the service will reside in, and add a Maintenance Window if needed.
  4. Select Projects in the Request Application field.
  5. Select the appropriate project type in the Request Type field.
  6. Choose the text to appear on the Request Service button in the service catalog.
  7. Add Tags for the service to make it easier to search for it.
  8. Click the Save button.

Creating an Informational (Non-Requestable) Service

To create an informational service that does allow a user to submit a request:

  1. In your Services application in Client Portal, click the New Service button.
  2. Select the Category this service will primarily reside in.
  3. Add the Name, Short Description, Long Description, add ordering, select the Manager for the service, choose the Assets/CIs application the service will reside in, and add a Maintenance Window if needed.
  4. Select None in the Request Application field.
  5. Add Tags for the service to make it easier to search for it.
  6. Click the Save button.

Editing and Managing Services

To edit the description of an existing service:

  1. In TDClient, navigate to Services > [service category] > [service to modify]
  2. Click Edit Service
  3. In the Content tab, update or modify the name, long description, and short description of the service.
  4. Click Save.

To modify the settings of a service:

  1. In TDClient, navigate to Services > [service category] > [service to modify]
  2. Click Edit Service
  3. In the Settings tab, update or modify the category, manager/owner, request application and type, and the request service button text.
  4. Click Save.

To modify the form used by a service:

  1. In TDClient, navigate to Services > [service category] > [service to modify]
  2. Click Edit Service
  3. In the Form tab, update or modify the form (if it is a service-specific form) and the public requestor settings.
  4. Click Save.

To modify the visibility permissions of a service:

  1. In TDClient, navigate to Services > [service category] > [service to modify]
  2. Click Edit Service
  3. In the Permissions tab, update or modify the visibility permissions of the service.
  4. Click Save.

To add relationships to individual assets/CIs:

  1. In TDClient, navigate to Services > [service category] > [service to modify]
  2. Click Edit Service
  3. Select the Relationships tab
  4. Click Add
  5. Choose a Relationship Type
  6. Choose one or more items to associate with the selected relationship type
  7. Click Save.

To add or manage related knowledge base articles:

  1. In TDClient, navigate to Services > [service category] > [service to modify]
  2. Click Edit Service
  3. In the Related Articles tab, select related articles to add to the service.
  4. Click Add.

To add file attachments to a service:

  1. In TDClient, navigate to Services > [service category] > [service to modify]
  2. Click Edit Service
  3. In the Files tab, click +Add to select files to attach to your service.

EDUCAUSE Center for Analysis and Research (ECAR)/TDX Mappings

If you are unsure how you want to organize your service catalog and ticket types, try starting with the structure outlined in the ECAR article on Service Catalogs and mapping the categories and terms to TeamDynamix components and terms.  With the addition of Service Categories in 11.3, there are now a few options for this approach, depending upon your reporting needs.

Simple Structure Option

This is recommended for most organizations where service category reporting is not required in TDNext and for those who wish to keep their back end structure simple.  It uses a single ticket type category for the department, which is great for ESM clients, and a single ticket type to keep structure easy to maintain.  Additional ticket types can be introduced if a technical configuration need is needed (i.e. different default time types, different reviewers, etc.).

  • ECAR Service Categories = TDX Service Category or subcategory (TDClient reporting)
  • ECAR Services = TDX Service (both TDNext and TDClient reporting)
  • ECAR Service Offering = TDX Service Offering (both TDNext and TDClient reporting)
  • ECAR Service Attributes = TDX Service Descriptions and/or TDX Custom attributes on TDX Services (both TDNext and TDClient reporting)
  • ECAR Service Offering Attributes = TDX Service Offering descriptions and/or TDX Custom attributes on TDX Service Offerings (both TDNext and TDClient reporting)

Simple tickets versus service catalog structure

Moderate Structure Option
Complex Structure (Full ECAR back end)

Frequently Asked Questions (FAQs)

Q. What is the definition of a service?

A. ITIL's definition of a service is "a means of providing value through facilitating outcomes for customers without the ownership of specific costs and risks." However, much like the Project Management Body of Knowledge’s (PMBOK) definition of a project, this definition is less helpful in practice. The term service can actually apply to several levels of a service: from the lines of service that a board or cabinet may want to see, to the services advertised to customers around campus, to specific service offerings that can be ordered. In TeamDynamix, the service catalog services best map service offerings.

Q. What is the best way to structure our service catalog?

A. Ideally, you can conduct usability analysis to test your service catalog structure with your end users. That said, consider also that your users may use search to find services. It is also possible to link people directly to services and/or service offerings. There is no one best organizational structure for the catalog.

Q. The service catalog seems overwhelming – where do I begin?

A. Ideally, begin with your most common requests. Your service catalog will have the most return when it helps to streamline the provisioning of common requests. A good service catalog should collect all the data you need upfront and route these requests directly to the teams or, in some cases, tools that can best provision them.

Q. Should I limit some services to logged-in users or to certain groups?

A. Service permissions can be controlled at the category or the service entry level. Permissions control whether people can see the service. If you require logins to see certain services, ensure that your users will know to log in to see those services. If you want to restrict services further, use TeamDynamix groups to restrict service. Please note that this adds additional overhead for you to populate and maintain group membership.

Q. Should I create catch-all services for requests that don't match anything else?

A. It is very common to create one or several catch-all services such as Need help? or Other enhancement request. The advantage of these catch-all requests is that users can put in requests rather than email or call your service desk. The disadvantage is that these requests cannot be routed directly to a group, and don't collect all the information needed. There's no one right answer but you can consider conducting a usability study on your service catalog to help design it so that these catch-all services are used as a last resort.

Q. Should I allow public requestors for services?

A. Ticket requests can have public requestors, which means that anyone in the world can request these services. If you turn on public requestors, carefully consider how to indicate to your support staff that these requests came in from the public – no one had to log in to order these services. One way to do this is by keeping requestor matching mode off.

Gotchas & Pitfalls

Organizations without a service catalog often try to define every possible service, which will add time to the implementation.

The more complex the review and approval process, the riskier implementation of this module becomes. The more people involved, and the more levels of approval involved, the longer implementing this module will take.

TeamDynamix encourages our clients to use a minimum viable product (MVP) approach to their service catalog.

Examples

professionalservices.teamdynamix.com, the TeamDynamix sample service catalog based on great service catalogs we've seen.

Here are links to several TeamDynamix clients that have used the application to publish their service catalogs:

Resources

  • Getting started with the client portal, for information on styling the client portal
  • Treejack, usability testing tool for decision trees (such as your service catalog hierarchy)
  • Higher Education IT Management list of Higher Education Service Catalogs.
  • Defining Services Template attachment in the Attachments section of this article.
    • Columns A, B, and D (Service, Owning Person/Team, and Short Description) will directly translate to fields used when creating services in TDX.
    • Column C (Needed Information for Request to Be Completed) will translate to attributes that will need to be created when configuring forms.
    • Columns E–I (What Is It? Who Is Eligible to Use It? Where Can I Get It? How Do I Use It? How Much Does It Cost?) are flexible (i.e., change them to best fit your organization, if necessary) and will help define a template for service descriptions (see the Article and Service Templates article).

Details

Details

Article ID: 12445
Created
Fri 4/22/16 10:26 AM
Modified
Thu 11/7/24 9:32 PM

Related Articles

Related Articles (6)

This article will help TeamDynamix Administrators and Client Portal Application Administrators to create Service Catalog and Knowledge Base article templates.
This how-to article will help TeamDynamix Administrators create Services in the Client Portal using TDClient and TDAdmin.
This article details common features and customizations of the TDX Client Portal, which provides public-facing content for clients without either TDX accounts or TDNext access.
The article provides a listing of links to client portals from TeamDynamix clients.
This article describes how to create and work with Service Offerings. Service Offerings are a component of a Service, which include their own details, their own form and settings, and their own configuration item and relationships.

Attachments

;